yahoo-eng-team team mailing list archive

[Lance Bragstad <lbragstad@xxxxxxxxx>]

Public bug reported:

Currently, both the registered_limit and limit tables use a UUID as the
primary key:

http://paste.openstack.org/raw/723936/

Instead of using this pattern, we can optimize for performance by using
an auto-incrementing primary key as the "internal_id" of the limit or
registered limit. The id column can remain as the ID of the entity
exposed through the API. The limit.id and registered_limit.id columns
should also maintain unique constraints.

Possibly migrations to address this improvement were whiteboarded in the
following etherpad:

https://etherpad.openstack.org/p/keystone-unified-limit-migration-
notepad

** Affects: keystone
     Importance: Medium
         Status: Triaged


** Tags: limits sql

** Changed in: keystone
       Status: New => Triaged

** Changed in: keystone
   Importance: Undecided => Medium

** Tags added: limits sql

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1777893

Title:
  Limit and registered limit tables should auto-increment primary keys

Status in OpenStack Identity (keystone):
  Triaged

Bug description:
  Currently, both the registered_limit and limit tables use a UUID as
  the primary key:

  http://paste.openstack.org/raw/723936/

  Instead of using this pattern, we can optimize for performance by
  using an auto-incrementing primary key as the "internal_id" of the
  limit or registered limit. The id column can remain as the ID of the
  entity exposed through the API. The limit.id and registered_limit.id
  columns should also maintain unique constraints.

  Possibly migrations to address this improvement were whiteboarded in
  the following etherpad:

  https://etherpad.openstack.org/p/keystone-unified-limit-migration-
  notepad

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1777893/+subscriptions