[Pulp-dev] 'id' versus 'pulp_id' on Content
amacdona at redhat.com
Wed May 23 13:36:29 UTC 2018
In Pulp 2, having id fields bit us really badly. The reason may have been
specific to Mongoengine, but my understanding is that it is bad practice
On Wed, May 23, 2018 at 9:22 AM, David Davis <daviddavis at redhat.com> wrote:
> Correct me if I’m wrong but don’t we call pk in most places instead of id?
> If so, it would seem like replacing id with pulp_id wouldn’t be that ugly.
> Also, I wonder about the created and last_updated fields. Seems like those
> could cause conflicts in the future too. At the very least, it might be
> nice to document which field names are reserved on the Content model.
> On Wed, May 23, 2018 at 8:50 AM, Brian Bouterse <bbouters at redhat.com>
>> Currently the Content model  has 'id' as it's primary key which is
>> inherited from MasterModel here . By naming our pk 'id', we are
>> preventing plugin writers from also using that field. That field name is
>> common for content types. For example: both RPM and Nuget content also
>> expect to use the 'id' field to store data about the content type itself
>> (not Pulp's pk). We learned about the Nuget incompatibility at
>> ConfigMgmgtCamp from a community member. I learned about this issue with
>> RPM from @dalley.
>> The only workaround a plugin writer has is to call their field 'rpm_id'
>> or something like that. I don't see how it's unavoidable that this renaming
>> won't be passed directly onto the user for things like filtering, creating
>> units, etc. I think that is an undesirable outcome just so that the Pulp pk
>> can be named 'id'.
>> One option would be to rename 'id' to 'pulp_id' at the MasterModel. This
>> is also somewhat ugly for Pulp developers, but it would be (a) crystal
>> clear to the user in all cases and (b) allow Content writers to model their
>> content types correctly.
>> Another option would be to rename the pk for 'Content' specifically and
>> not at the MasterModel level. I think that would create more confusion than
>> benefit so I recommend doing it at the MasterModel level.
>> What do you all think?
>> : https://github.com/pulp/pulp/blob/6f492ee8fac94b8562dc62d87e
>> : https://github.com/pulp/pulp/blob/d1dc089890f167617fe9917af0
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
> Pulp-dev mailing list
> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev