yahoo-eng-team team mailing list archive

[OpenStack Infra <1777893@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/576025
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=209462c90d44df7bf58fd3786887047adefdc22b
Submitter: Zuul
Branch:    master

commit 209462c90d44df7bf58fd3786887047adefdc22b
Author: wangxiyuan <wangxiyuan@xxxxxxxxxx>
Date:   Mon Jun 18 11:39:31 2018 +0800

    Add auto increase primary key for unified limit
    
    What this patch did and why:
    
    1. added an auto increment primary column `interenal_id` for both
       registered_limit and limit tables. Removed the primary key but
       added unique index for `id` column. This change can improve
       the db performance.
    2. dropped the forieign keys in limit table. The `project_id`
       column has a foreign key. Using foreign key between different
       backends can lead some unexpected error.
    3. dropped the unique constraints and foreign key constraint in both
       tables. Because `region_id` can be null, in this case, both
       constraints can't work well in all kinds of DBs. Instead, we'll
       check the unique and foreign reference in code.
    
    NOTE: For MySQL and PostgreSQL, we did the change inner tables. But
    for SQLite, it doesn't support adding a primary column into an existed
    table, so that we recreated the tables instead..
    
    Closes-bug: #1777893
    Change-Id: Ibb408758466ff367f57bafbd4b8c9213499f8dc3


** Changed in: keystone
       Status: In Progress => Fix Released

-- 
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):
  Fix Released

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