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

Simon Baatz gmbnomis at gmail.com
Thu Jun 14 17:32:12 UTC 2018

My 2 cents (in my role as a user, not plugin writer): I think the most
important argument in the entire discussion is this (not sure who
said this):

>    * plugin users (not writers) who are familiar with 'id' as part of the
>    erratum data type would then have to also understand this field name
>    renaming that Pulp arbitrarily introduces. This could get confusing
>    when the user submit a filter with id='ID-2115858' and they find
>    nothing because 'id' is matching on the primary key not on the 'id'
>    attribute of the errata like they expect. Those users would also be
>    Pulp users so they'll understand that _id means the pk.
>    By the same logic, if Pulp users know that id means pk, wouldn’t they
>    therefore understand that the id is not the erratum id?
>    Yes by that logic they probably would know, but the actual errata field
>    is named 'id' so my it's more about a correctness problem than
>    confusion. A correctness problem that passes along to users. If we're
>    going to have confusing names, let's pick names that allow for
>    alignment with the names already chosen by content types which commonly
>    do use 'id'. Plugin writer's aren't in control of those names; they
>    already are chosen by content types.

Assuming that Pulp users are aware of a pk named 'id' is a strong
assumption.  If the user is just managing entire repositories and
searches content from time to time when troubleshooting (using a CLI
for example), she/he could not care less that there is a field called
"id" that is not what it seems to be.

I think the entire discussion is focused on plugin writers too much.
The user visible consequences of this decision are more important from
my point of view. 

The situation is not directly comparable, but I already had fun with
confusing id names [0] in the CLI.  I must have been rather annoyed
at the time, since I still remember ;-)

[0] https://www.redhat.com/archives/pulp-list/2016-March/msg00048.html

More information about the Pulp-dev mailing list