[Pulp-dev] 'id' versus 'pulp_id' on Content

[Dana Walker]

While I have not given your suggestion a lot of thought yet, it seems
sound.  I'd been wondering about the state of this discussion recently and
had already decided I'm onboard with whatever the majority decides merely
to get us moving again.

I want us to make good decisions so as to increase adoption of Pulp, but
for that to even matter, we need it finished and to swap to Pulp 3 from
Pulp 2.  At this point, I'm willing to say let's just pick what most prefer
and move forward (and that goes for any of these design discussions) and if
given the power of hindsight we'd like to make different decisions, we can
do so in Pulp 4.

--Dana

Dana Walker

Associate Software Engineer

Red Hat

<https://www.redhat.com>
<https://red.ht/sig>

On Tue, Aug 7, 2018 at 1:23 PM, Daniel Alley <dalley at redhat.com> wrote:

> With this in mind, I'm thinking that the leading underscore (_) could be
>> used broadly to denote *generated* *or metadata* fields and the
>> following would be reasonable:
>>
>
> I'm on board with this, I think your revised description of what '_' could
> symbolize makes a lot of sense.
>
>
>
> On Tue, Aug 7, 2018 at 12:47 PM, Jeff Ortel <jortel at redhat.com> wrote:
>
>> After long consideration, I have had a change of heart about this.  I
>> think.  In short, Pulp's data model has unique requirements that make it
>> acceptable to deviate from common convention regarding ID as the PK.
>> Mainly that the schema is extensible by plugin writers.  Given the plugin
>> architecture, I think it's reasonable to think of "core" fields like: ID,
>> CREATED and LAST_MODIFIED as metadata.  Although, the ID is harder to fit
>> in this semantic, I think it's reasonable to do for consistency and to
>> support the user query use-case re: content having an natural ID
>> attribute.  Taking this further, the *href* attributes *could* be though
>> of in the same category.
>>
>> With this in mind, I'm thinking that the leading underscore (_) could be
>> used broadly to denote *generated* *or metadata* fields and the
>> following would be reasonable:
>>
>> _id
>> _created
>> _last_updated
>>
>> _href
>> _added_href
>> _removed_href
>> _content_href
>>
>> I highly value consistency so this applies to the entire schema.
>>
>> This will introduce a few fairly odd things into the schema that I
>> *suppose* we can live with.
>>
>> - Two fields on *some* tables named (ID ,  _ID).  To mitigate confusion,
>> we should serialize the *pk* and not* _id*.  This will also be
>> consistent with *pk* parameters passed in.
>> - I expect django will generate foreign key fields with double
>> understores.  Eg: content__id
>>
>> I'm still -1 for using a *pulp_* prefix.
>>
>> Thoughts?
>>
>>
>> On 06/18/2018 01:15 PM, Daniel Alley wrote:
>>
>> I'm -1 on going the underscore idea, partly because of the aforementioned
>> confusion issue, but also partly because but I've noticed that in our API,
>> the "underscore" basically has a semantic meeting of "href, [which is]
>> generated on the fly, not stored in the db".
>>
>> Specifically:
>>
>>    - '_href'
>>    - '_added_href'
>>    - '_removed_href'
>>    - '_content_href'
>>
>> So I think if we use a prefix, we should avoid using one that already has
>> a semantic meaning (I don't know whether we actually planned for that to be
>> the case, but I think it's a useful pattern / distinction and I don't think
>> we should mess with it).
>>
>>
>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180807/5e1b8bf4/attachment.htm>