<div dir="ltr"><div dir="ltr"><div>@dalley that is an excellent writeup of what is going on.</div><div><br></div><div>So since we could be benefitting from PostgreSQL-only Django features, I think we should add MySQL to the test matrix to ensure that at least pulp/pulp and pulp/pulpcore-plugin are SQL agnostic. I made this issue here to track that work. <a href="https://pulp.plan.io/issues/4270" target="_blank">https://pulp.plan.io/issues/4270</a></div><div><br></div><div>Please raise any concerns or ideas on what we could do better for this.<br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 5, 2018 at 1:34 PM Daniel Alley <<a href="mailto:dalley@redhat.com" target="_blank">dalley@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>To rephrase the problem a little bit:</div><div><br></div><div>We need to bulk_create() a bunch of objects, and then after we do that we want to immediately be able to relate them with other objects, which means we need their PKs of the objects that were just created. <br></div><div><br></div><div>In the case of auto-increment integer PKs, we can't know that PK value before it gets saved into the database.  Luckily, PostgreSQL (and Oracle) support a "RETURNING" keyword that does provides this information.  The raw SQL would look something like this:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><pre><span class="gmail-m_5032646588573793995gmail-m_-6034838772108643300gmail-k">INSERT</span> <span class="gmail-m_5032646588573793995gmail-m_-6034838772108643300gmail-k">INTO</span> <span class="gmail-m_5032646588573793995gmail-m_-6034838772108643300gmail-n">items</span> <span class="gmail-m_5032646588573793995gmail-m_-6034838772108643300gmail-p">(</span><span class="gmail-m_5032646588573793995gmail-m_-6034838772108643300gmail-n">name</span><span class="gmail-m_5032646588573793995gmail-m_-6034838772108643300gmail-p">)</span> <span class="gmail-m_5032646588573793995gmail-m_-6034838772108643300gmail-k">values</span> <span class="gmail-m_5032646588573793995gmail-m_-6034838772108643300gmail-p">(</span><span class="gmail-m_5032646588573793995gmail-m_-6034838772108643300gmail-s1">'bear'</span><span class="gmail-m_5032646588573793995gmail-m_-6034838772108643300gmail-p">)</span> <span class="gmail-m_5032646588573793995gmail-m_-6034838772108643300gmail-n">RETURNING</span> <span class="gmail-m_5032646588573793995gmail-m_-6034838772108643300gmail-n">id</span><span class="gmail-m_5032646588573793995gmail-m_-6034838772108643300gmail-p">;</span></pre></div></blockquote><div>Django uses this feature to set the PK field on the model objects it returns when you call bulk_create() on a list of unsaved model objects.<br></div><div><br></div><div>Unfortunately, MySQL doesn't support this, so there's no way to figure out what the PKs of the objects you just saved were, so the ORM can't set that information on the returned model objects.<br></div><div><br></div><div>UUID PKs circumvent this because the PK gets created outside of the database, prior to being saved in the database, and so Django *can* know what the PK will be when it gets saved.<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 5, 2018 at 12: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>+1 to experimentation and also making sure that we understand the performance implications of the decision. I'm replying to this earlier note to restate my observations of the problem a bit more.</div><div><br></div><div>More ideas and thoughts are welcome. This is a decision with a lot of aspects to consider.</div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 20, 2018 at 10:00 AM Patrick Creech <<a href="mailto:pcreech@redhat.com" target="_blank">pcreech@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">On Mon, 2018-11-19 at 17:08 -0500, Brian Bouterse wrote:<br>
> When we switched from UUID to integers for the PK<br>
> with databases other than PostgreSQL [0].<br>
> <br>
> With a goal of database agnosticism for Pulp3, if plugin writers plan to use bulk_create with any object inherited<br>
> from one of ours, they can't will get different behaviors on different databases and they won't have PKs that they may<br>
> require. bulk_create is a normal django thing, so plugin writers making a django plugin should be able to use it. This<br>
> concerned me already, but today it was also brought up by non-RH plugin writers also [1] in a PR.<br>
> <br>
> The tradeoffs bteween UUIDs versus PKs are pretty well summed up in our ticket where we discussed that change [2].<br>
> Note, we did not consider this bulk_create downside at that time, which I think is the most significant downside to<br>
> consider.<br>
> <br>
> Having bulk_create effectively not available for plugin writers (since we can't rely on its pks being returned) I<br>
> think is a non-starter for me. I love how short the UUIDs made our URLs so that's the tradeoff mainly in my mind.<br>
> Those balanced against each other, I think we should switch back.<br>
> <br>
> Another option is to become PostgreSQL only which (though I love psql) I think would be the wrong choice for Pulp from<br>
> what I've heard from its users.<br>
> <br>
> What do you think? What should we do?<br>
<br>
So, my mind immediately goes to this question, which might be usefull for others to help make decisions, so I'll ask:<br>
<br>
When you say: <br>
<br>
"we lost the ability to have the primary key set during bulk_create"<br>
<br>
Can you clarify what you mean by this?<br>
<br>
My mind immediately goes to this chain of events:<br>
<br>
        When you use bulk_create, the existing in-memory model objects representing the data to create do not get<br>
updated with the primary key values that are created in the database.  <br>
<br>
        Upon a subsequent query of the database, for the exact same set of objects just added, those objects _will_ have<br>
the primary key populated.<br>
<br>
In other words, <br>
<br>
        The database records themselves get the auto-increment IDs added, they just don't get reported back in that<br>
query to the ORM layer, therefore it takes a subsequent query to get those ids out.<br>
<br>
Does that about sum it up?<br></blockquote><div><br></div><div>Yes this describes the situation, but there is a bit more to tell. Since PostgreSQL does return the ids the subsequent query that could be done to get the ids isn't written in code today. We didn't need to because we developed it against PostgreSQL. I'm pretty sure that if you configure Pulp against MySQL Pulp won't work, which I think is a problem. So I'm observing two things here. 1) This is a hazard that causes code to unexpectedly be only compliant with PostgreSQL. 2) Pulp itself fell into this hazard and we need to fix that too</div><div><br></div><div>Do you also see these two issues? What should be done about these?<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
> <br>
> [0]: <a href="https://docs.djangoproject.com/en/2.1/ref/models/querysets/#bulk-create" rel="noreferrer" target="_blank">https://docs.djangoproject.com/en/2.1/ref/models/querysets/#bulk-create</a><br>
> [1]: <a href="https://github.com/pulp/pulp/pull/3764#discussion_r234780702" rel="noreferrer" target="_blank">https://github.com/pulp/pulp/pull/3764#discussion_r234780702</a><br>
> [2]: <a href="https://pulp.plan.io/issues/3848" rel="noreferrer" target="_blank">https://pulp.plan.io/issues/3848</a><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>
<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></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>
</blockquote></div>