<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body>
Please find the response inline.<br>
<blockquote
cite="mid:OF9CF51954.2E74FD78-ON48257E7E.000E29CC-48257E7E.000EB975@cn.ibm.com"
type="cite">
<p><font size="2" face="sans-serif">Hi Glance experts,</font><br>
<br>
<font size="2" face="sans-serif">I'd like to send this mail
again, hope I can get help and suggest from glance experts.
The question is from a bug </font><a moz-do-not-send="true"
href="https://bugs.launchpad.net/glance/+bug/1462315"><font
size="2" face="sans-serif">https://bugs.launchpad.net/glance/+bug/1462315</font></a><font
size="2" face="sans-serif">, </font><br>
<br>
<tt><font size="2">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, </font></tt><br>
<tt><font size="2">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.</font></tt><br>
<br>
<font size="2" face="serif">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</font><br>
<font size="2" face="serif">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. </font><br>
<br>
</p>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:OF9CF51954.2E74FD78-ON48257E7E.000E29CC-48257E7E.000EB975@cn.ibm.com"
type="cite">
<p>
<tt><font size="2">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 </font></tt><a
moz-do-not-send="true"
href="https://review.openstack.org/#/c/190895/"><tt><font
size="2">https://review.openstack.org/#/c/190895/</font></tt></a><br>
<br>
<br>
<font size="2" face="serif">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.</font><br>
<br>
<br>
</p>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:OF9CF51954.2E74FD78-ON48257E7E.000E29CC-48257E7E.000EB975@cn.ibm.com"
type="cite">
<p>
<font size="2" face="sans-serif">Best regards,</font><br>
<font size="2" face="sans-serif">LongQuan</font><br>
<br>
<br>
</p>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Thanks,
Nikhil</pre>
</body>
</html>