[Pulp-dev] 'id' versus 'pulp_id' on Content
daviddavis at redhat.com
Fri Jun 8 20:13:04 UTC 2018
I did a quick test and it looks like pk can't be used as a field name:
pulp_app.HelloWorld.pk: (fields.E003) 'pk' is a reserved word that cannot
be used as a field name.
This kind of leads me to believe that there are going to be certain field
names that plugin writers simply cannot use and trying to ameliorate this
situation isn’t going to work.
On Fri, Jun 8, 2018 at 3:57 PM, Brian Bouterse <bbouters at redhat.com> wrote:
> @dalley: I agree we have practical reasons motivating the 3 field name
> changes, of which the most important is 'id' to '_id'. w.r.t using "
> object.pk", that could create similar problems. If a plugin writer
> defines a 'pk' field then core code using using 'object.pk' will cause
> core code to receive their attribute and not the primary key. I think
> overall the strategy I think to minimize collisions we should use
> 'object._id' directly. How does that sound?
> @jortel: We're blocked on your -1 vote expressed for 3704. We have
> practical plugin writer issues with the current state. Can you elaborate on
> why we shouldn't go forward with https://pulp.plan.io/issues/3704
> On Thu, Jun 7, 2018 at 1:52 PM, Daniel Alley <dalley at redhat.com> wrote:
>> The article you mentioned states that 'ID' *should* be used for the PK
>> It does say this, but it says that the reasons for doing that are because
>> id is "short, simple, and unambiguous", and that the reason you shouldn't
>> prefix is because "the extra prefix is redundant". I think it's really
>> good advice for the general case, but the reasoning is based in
>> practicality and not strong convention, and in our case we do have some
>> other practical reasons to not do this.
>> I don't feel super strongly in either direction at this point. I think
>> my personal preference is to change "id" to something else, and use a
>> convention of "object.pk" instead of "object.id". The "pk" attribute
>> maps to whatever the primary key if we use that, we don't need to care what
>> the field is called.
>> Re: Brian
>> When encountered, what they expressed is "Why would Pulp reserve common
>>> field that I need to define on my subclass?" My feeling here is that we
>>> don't actually have a good reason.
>> "id" is technically reserved (unless you override it) by Django, since it
>> is the default PK field. If they were to directly subclass
>> `django.db.models.Model` they would have the same problem. This is the
>> only reason I'm a little conflicted, otherwise I be 100% in favor of
>> changing it.
>> On Tue, May 29, 2018 at 12:46 PM, Jeff Ortel <jortel at redhat.com> wrote:
>>> On 05/29/2018 08:24 AM, Brian Bouterse wrote:
>>> On Fri, May 25, 2018 at 7:39 PM, Dana Walker <dawalker at redhat.com>
>>>> I'm basically -1 for the reasons Jeff enumerated but if he is ok with
>>>> this, I'm happy to go ahead with it.
>>>>> In classic relational modeling, using ID as the primary key is common
>>>>> practice. Especially when ORMs are involved. The "id" added by plugin
>>>>> writers is a natural key so naming it ID goes against convention.
>>>> This is echoed here, for further reading (though perhaps this article
>>>> is overly simplified for our needs) in the sections "Key Fields" and
>>>> "Prefixes and Suffixes (are bad)":
>>> That is true, but this article also talks about avoiding reserved words
>>> as well. I think we're hearing 'id' is a commonly reserved word for content
>>> types being modeled by plugin writers.
>>> The article you mentioned states that 'ID' *should* be used for the
>>> PK which means it is inappropriate for natural key fields defined by plugin
>>> writers. The reserved words caution in the article are DDL/DML reserved
>>> words "Ex: Avoid using words like user, lock, or table." not reserved
>>> by plugins.
>>>  https://launchbylunch.com/posts/2014/Feb/16/sql-naming-conve
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>> 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