Thanks for your comment, Simon.
This introduces a perspective that is helpful to the discussion.
Filtering on an 'ID' natural key field (such as errata_ID) in a way that
is intuitive to the user is a significant use case.
On 06/14/2018 12:32 PM, Simon Baatz wrote:
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
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
