When we switched from UUID to integers for the PK we lost the ability to have the primary key set during bulk_create with databases other than PostgreSQL [0].
With a goal of database agnosticism for Pulp3, if plugin writers plan to use bulk_create with any object inherited from one of ours, they can't will get different behaviors on different databases and they won't have PKs that they may require. bulk_create is a normal django thing, so plugin writers making a django plugin should be able to use it. This concerned me already, but today it was also brought up by non-RH plugin writers also [1] in a PR. The tradeoffs bteween UUIDs versus PKs are pretty well summed up in our ticket where we discussed that change [2]. Note, we did not consider this bulk_create downside at that time, which I think is the most significant downside to consider. Having bulk_create effectively not available for plugin writers (since we can't rely on its pks being returned) I 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. Those balanced against each other, I think we should switch back. Another option is to become PostgreSQL only which (though I love psql) I think would be the wrong choice for Pulp from what I've heard from its users. What do you think? What should we do? [0]: https://docs.djangoproject.com/en/2.1/ref/models/querysets/#bulk-create [1]: https://github.com/pulp/pulp/pull/3764#discussion_r234780702 [2]: https://pulp.plan.io/issues/3848
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
