Please find the response inline. > > Hi Glance experts, > > I'd like to send this mail again, hope I can get help and suggest from > glance experts. The question is from a bug > https://bugs.launchpad.net/glance/+bug/1462315, > > If an image-member is deleted, then create it again with the same > parameters, glance searches db to see if there is already an existing > one, but the result doesn't include the record which was marked as > deleted, > glance will try to create a new one with the same parameters, it works > well on mysql. But it is failed on DB2 with SQL0803N error. > > The root cause is that DB2 constraint is more restricted than mysql. > For db2, the columns under unique constrains should be "NOT NULL", > currently the column "deleted_at" which is one of unique constrain of > image_members > is nullable. A possible solution is to alter it to "not null" in > migration. that means we have to insert a default timestamp value for > the new created image-member, an active member with a no-blank > timestamp for "deleted_at" seems very confusing. >
Agree that this is confusing. And changing the behavior this way is NOT a good idea. A record that's never been deleted should not have deleted(_at) value. It will affect notifications and conflict with API guidelines. > Another fix is: we may check all existing image-member records > including the deleted image-member before create image-member, then > update it if it exists, otherwise create a new one, that is proposed > in https://review.openstack.org/#/c/190895/ > > > I'm wondering why can't we use only one record to maintain the > member-ship between a pair of image and tenant. Maybe there is some > other consideration, can you help give me some suggestion ? I'd like > to know more. Thanks. > > Concept wise this sounds like a good idea but it could have performance degradation impact. Nonetheless, image-members have an idx that should be a relief for that query image_member_find that you added in your proposal. My hope is that the rally gate job will tell us more if there is a performance problem. > Best regards, > LongQuan > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, Nikhil
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
