<div dir="ltr"><div dir="ltr"><div>Brian, that's an excellent writup, thanks!</div><div><br></div><div>From what I can tell, it looks very very unlikely that MySQL will add the "returning" syntax.  MariaDB however has supported "returning" for DELETE operations *only* for about 5 years, and has a 2 year old issue to add it for "INSERT" <a href="https://jira.mariadb.org/browse/MDEV-10014" target="_blank">https://jira.mariadb.org/browse/MDEV-10014</a> <br></div><div><br></div><div>However, it also seems like Django takes the "common denominator" approach towards supporting them (since they are so similar, it treats them as the same database), so even if one or the other were to add support, I doubt that functionality would be exposed through the ORM unless they *both* were to support it.  Therefore I think we can assume we won't see that functionality any time soon.</div><div><br></div><div>I'll probably do the performance investigation as described in #4290 some time late next week.  I'd like for some of the refactoring that has been going on in the stages API to be completed before I proceed with that.<br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 16, 2019 at 4:11 PM Brian Bouterse <<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Today @jortel, @dalley, @daviddavis, and @asmacdo been taking a look at our options in terms of resolving the PK issue that prevents Pulp from running on MariaDB. After considering various of possible solutions on a call, and @dalleydoing a little bit of research into the feasibility of those, I believe there are only two options:</div><div><br></div><div>A) switch to UUIDs or B) implement a fallback that saves one at a time if there's no "RETURNING".</div><div><br></div><div>In reflecting on this, I have two observations about option (B). First, the root cause of this is that MariaDB doesn't implement the "RETURNING" option like PostgreSQL and Oracle does. The best solution would be for MariaDB to do that. If they aren't able to fix it where the problem is created, investing a good deal of time and energy into how to make Pulp run fast on MariaDB doesn't seem worth it to me. Secondly, our fallback to one-by-one mode would effectively cause Pulp sync on MariaDB to experience the slowdowns described in this ticket [0] which were generally identified as unacceptable for Pulp users. In terms of timeline, since we had talked about MariaDB compatibility being an RC blocker, I don't think we want to wait for MariaDB to make any changes, like an implementation for "RETURNING".<br></div><div><br></div><div>In thinking about option (A) it resolves the compatibility issue and allows plugin writers to avoid the "my dbs don't work the same with bulk_create" problem entirely, so it's a great solution to the central problem (db compatibility). My only concern with (A) is that we know it is a some amount slower in terms of write performance, read performance, and index size concerns. @dalley has an issue written up [1] to look at the impact of adopting (A) on Pulp workloads.<br></div><div><br></div><div>So the next step would be to complete [1] and share the results. After looking at them we would yes/no the adopting of UUIDs as likely our only feasible resolution. Any other ideas on what to do or how to do it are welcome.<br></div><div><br></div><div>[0]: <a href="https://pulp.plan.io/issues/3770" target="_blank">https://pulp.plan.io/issues/3770</a></div><div>[1]: <a href="https://pulp.plan.io/issues/4290" target="_blank">https://pulp.plan.io/issues/4290</a></div><div><br></div><div>-Brian</div><div><br></div><div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 9, 2019 at 1:41 PM Matthias Dellweg <<a href="mailto:dellweg@atix.de" target="_blank">dellweg@atix.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 9 Jan 2019 08:46:18 -0500<br>
David Davis <<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>> wrote:<br>
<br>
> The Rubygems api includes sha as part of the metadata for a gem.<br>
> Couldn't you use that as part of the natural key?<br>
> <br>
> I'm surprised that Chef's supermarket API doesn't include this as<br>
> well. Maybe we could open a feature request?<br>
> <br>
> David<br>
<br>
WRT rubygems i use repositories generated by `gem generate_index`.<br>
There is no chechsum in the metadata that i found.<br>
But also the whole thing seems to be documented rather poorly.<br>
Using <a href="http://rubygems.org" rel="noreferrer" target="_blank">rubygems.org</a> as a remote is not adviseable until there are proper<br>
filters implemented. ;)<br>
  Matthias<br>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>