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

[Brian Bouterse]

Jeff, can you elaborate more on your -1. I want to understand it. I'm
struggling to appreciate an "it's a convention" argument without sources
like an RFC or similar. I don't believe internet articles are credible
sources because any viewpoint can be validated by an internet post.

To recap my interests here, it's about being responsive to the community.
We ask plugin writers for feedback and from two independent plugin writers
(not me) we received feedback that this name wasn't ideal. I want us to be
responsive to that. It's not only because I think their technical feedback
is legit (albeit small), but also because it's our strategy during the
beta/RC of Pulp3 core is to make adjustments based on plugin writer
feedback. To receive feedback and choose to not follow the recommendation
they suggested feels like not the way I want to interact with plugin
writers. This is my main concern with not making a change in this area.

All the best,
Brian


On Wed, Jun 13, 2018 at 10:26 AM, Jeff Ortel  wrote:

>
>
> On 06/12/2018 05:03 PM, David Davis wrote:
>
> I do think the most compelling case for renaming the field is having
> feedback from plugin writers to do so and also the desire to reduce
> complexity for plugin writers. Honestly, I am on the fence about renaming
> the field.
>
> Just to clarify, is anyone a hard -1 on renaming id?
>
>
> -1
>
>
>
>
> David
>
> On Tue, Jun 12, 2018 at 5:32 PM, Brian Bouterse 
> wrote:
>
>>
>>
>> On Tue, Jun 12, 2018 at 5:11 PM, David Davis 
>> wrote:
>>
>>> On Tue, Jun 12, 2018 at 4:50 PM, Brian Bouterse 
>>> wrote:
>>>
 Silly question, but could we just call our 'id' 'pk' instead? Since
 that is a fully reserved value in Django for the primary key it seems
 clearest to just use that? What about that?

>>>
>>> Are you recommending we rename the id field to pk in the database? I’m
>>> not sure if that would work.
>>>
>>
>> I'm wondering if its possible yes. #django says it is but they've been
>> wrong before. I haven't had a chance to test it.
>>
>>
>>>
>>>

 On Tue, Jun 12, 2018 at 3:44 PM, Jeff Ortel  wrote:

> On 06/08/2018 02:57 PM, Brian Bouterse wrote:
>
>>
>> @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
>>
>
> The 'ID' column is reserved for the primary key and is inappropriate
> for natural keys.  This is well establish convention and best practice.


 I don't understand this reasoning. Earlier in the thread we discussed
 how the sources recommending these conventions also mention that if we have
 a practical reason or problem with that convention to do something
 differently. We received complaints on this name about collisions so I
 don't follow how we should still follow the convention.


> Plugin writers specify natural keys.  Also, by introducing '_' prefix
> (or any prefix) means a table could have both 'ID' and '_ID' columns which
> is especially confusing since the 'ID' column would not be the primary 
> key.
>

 We have two concepts here that are similar, so I think that problem is
 mostly unrelated to this decision. For example, if we leave the names as-is
 we have this problem only now it's named id and errata_id and in addition
 we'll have the problems listed below.


> How does naming the natural key for an rpm as 'rpm_id' cause a
> significant problem for plugin writers?
>

 It's a good question because it's the whole motivation for this change.
 It's not an rpm, it's an erratum which doesn't have nevra like a package.
 It's also the problem from another content type I heard about at Config
 Management Camp.

 It causes problems in two ways:

 * 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 nam

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

[Dana Walker]

I'm -1 still but I had a few questions.

1) If we do this, what happens when someone uses multiple plugins and both
of them want to use id as well?  Wouldn't it be better to have the core
application reserving it and *all* plugins doing some derivative name?

2) I'd really like to hear more from the actual plugin writers desiring the
change on if this is a really big deal or just a minor complaint and if it
is important to them, have them write a story detailing why.  Who is the
best person for me to ask?  Someone on Satellite?  RPM?  Is someone reading
this who is effected and could give further details?

Thanks,

--Dana

Dana Walker

Associate Software Engineer

Red Hat




On Thu, Jun 14, 2018 at 9:08 AM, Brian Bouterse  wrote:

> Jeff, can you elaborate more on your -1. I want to understand it. I'm
> struggling to appreciate an "it's a convention" argument without sources
> like an RFC or similar. I don't believe internet articles are credible
> sources because any viewpoint can be validated by an internet post.
>
> To recap my interests here, it's about being responsive to the community.
> We ask plugin writers for feedback and from two independent plugin writers
> (not me) we received feedback that this name wasn't ideal. I want us to be
> responsive to that. It's not only because I think their technical feedback
> is legit (albeit small), but also because it's our strategy during the
> beta/RC of Pulp3 core is to make adjustments based on plugin writer
> feedback. To receive feedback and choose to not follow the recommendation
> they suggested feels like not the way I want to interact with plugin
> writers. This is my main concern with not making a change in this area.
>
> All the best,
> Brian
>
>
> On Wed, Jun 13, 2018 at 10:26 AM, Jeff Ortel  wrote:
>
>>
>>
>> On 06/12/2018 05:03 PM, David Davis wrote:
>>
>> I do think the most compelling case for renaming the field is having
>> feedback from plugin writers to do so and also the desire to reduce
>> complexity for plugin writers. Honestly, I am on the fence about renaming
>> the field.
>>
>> Just to clarify, is anyone a hard -1 on renaming id?
>>
>>
>> -1
>>
>>
>>
>>
>> David
>>
>> On Tue, Jun 12, 2018 at 5:32 PM, Brian Bouterse 
>> wrote:
>>
>>>
>>>
>>> On Tue, Jun 12, 2018 at 5:11 PM, David Davis 
>>> wrote:
>>>
 On Tue, Jun 12, 2018 at 4:50 PM, Brian Bouterse 
 wrote:

> Silly question, but could we just call our 'id' 'pk' instead? Since
> that is a fully reserved value in Django for the primary key it seems
> clearest to just use that? What about that?
>

 Are you recommending we rename the id field to pk in the database? I’m
 not sure if that would work.

>>>
>>> I'm wondering if its possible yes. #django says it is but they've been
>>> wrong before. I haven't had a chance to test it.
>>>
>>>


>
> On Tue, Jun 12, 2018 at 3:44 PM, Jeff Ortel  wrote:
>
>> On 06/08/2018 02:57 PM, Brian Bouterse wrote:
>>
>>>
>>> @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
>>>
>>
>> The 'ID' column is reserved for the primary key and is inappropriate
>> for natural keys.  This is well establish convention and best practice.
>
>
> I don't understand this reasoning. Earlier in the thread we discussed
> how the sources recommending these conventions also mention that if we 
> have
> a practical reason or problem with that convention to do something
> differently. We received complaints on this name about collisions so I
> don't follow how we should still follow the convention.
>
>
>> Plugin writers specify natural keys.  Also, by introducing '_' prefix
>> (or any prefix) means a table could have both 'ID' and '_ID' columns 
>> which
>> is especially confusing since the 'ID' column would not be the primary 
>> key.
>>
>
> We have two concepts here that are similar, so I think that problem is
> mostly unrelated to this decision. For example, if we leave the names 
> as-is
> we have this problem only now it's named id and errata_id and in addition
> we'll have the problems listed below.
>
>
>> How does naming the natural key for an rpm as 'rpm_id' cause a
>> significant problem for plugin writers?
>>
>
> It's a good question because it's the whole motivation for this
> change. It's not an rpm, it's an erratum which doesn't have nevra like a
> package. It's also the problem from another content type I heard about at
> Config Management Camp.
>
> It causes problems in two ways:
>
> * plugin users (not writers) who are familiar with 'id' as part of the
> erratum data type would then have to also unders

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

[Dennis Kliban]

On Thu, Jun 14, 2018 at 10:28 AM, Dana Walker  wrote:

> I'm -1 still but I had a few questions.
>

Why are you -1?


>
> 1) If we do this, what happens when someone uses multiple plugins and both
> of them want to use id as well?  Wouldn't it be better to have the core
> application reserving it and *all* plugins doing some derivative name?
>

Multiple plugins can have a model with a field name that is the same as a
model in another plugin.

The problem only exists when a plugin's model inherits from a pulpcore
model and tries to use a field name that is already used by the model it's
inheriting from.


>
> 2) I'd really like to hear more from the actual plugin writers desiring
> the change on if this is a really big deal or just a minor complaint and if
> it is important to them, have them write a story detailing why.  Who is the
> best person for me to ask?  Someone on Satellite?  RPM?  Is someone reading
> this who is effected and could give further details?
>
>
This was discussed during our workshop in Ghent back in February. I THINK
Alexander and Simon were the two people that brought this up. I know Simon
reads/writes on this list, but i am not sure about Alexander.


> Thanks,
>
> --Dana
>
> Dana Walker
>
> Associate Software Engineer
>
> Red Hat
>
> 
> 
>
> On Thu, Jun 14, 2018 at 9:08 AM, Brian Bouterse 
> wrote:
>
>> Jeff, can you elaborate more on your -1. I want to understand it. I'm
>> struggling to appreciate an "it's a convention" argument without sources
>> like an RFC or similar. I don't believe internet articles are credible
>> sources because any viewpoint can be validated by an internet post.
>>
>> To recap my interests here, it's about being responsive to the community.
>> We ask plugin writers for feedback and from two independent plugin writers
>> (not me) we received feedback that this name wasn't ideal. I want us to be
>> responsive to that. It's not only because I think their technical feedback
>> is legit (albeit small), but also because it's our strategy during the
>> beta/RC of Pulp3 core is to make adjustments based on plugin writer
>> feedback. To receive feedback and choose to not follow the recommendation
>> they suggested feels like not the way I want to interact with plugin
>> writers. This is my main concern with not making a change in this area.
>>
>> All the best,
>> Brian
>>
>>
>> On Wed, Jun 13, 2018 at 10:26 AM, Jeff Ortel  wrote:
>>
>>>
>>>
>>> On 06/12/2018 05:03 PM, David Davis wrote:
>>>
>>> I do think the most compelling case for renaming the field is having
>>> feedback from plugin writers to do so and also the desire to reduce
>>> complexity for plugin writers. Honestly, I am on the fence about renaming
>>> the field.
>>>
>>> Just to clarify, is anyone a hard -1 on renaming id?
>>>
>>>
>>> -1
>>>
>>>
>>>
>>>
>>> David
>>>
>>> On Tue, Jun 12, 2018 at 5:32 PM, Brian Bouterse 
>>> wrote:
>>>


 On Tue, Jun 12, 2018 at 5:11 PM, David Davis 
 wrote:

> On Tue, Jun 12, 2018 at 4:50 PM, Brian Bouterse 
> wrote:
>
>> Silly question, but could we just call our 'id' 'pk' instead? Since
>> that is a fully reserved value in Django for the primary key it seems
>> clearest to just use that? What about that?
>>
>
> Are you recommending we rename the id field to pk in the database? I’m
> not sure if that would work.
>

 I'm wondering if its possible yes. #django says it is but they've been
 wrong before. I haven't had a chance to test it.


>
>
>>
>> On Tue, Jun 12, 2018 at 3:44 PM, Jeff Ortel 
>> wrote:
>>
>>> On 06/08/2018 02:57 PM, Brian Bouterse wrote:
>>>

 @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

>>>
>>> The 'ID' column is reserved for the primary key and is inappropriate
>>> for natural keys.  This is well establish convention and best practice.
>>
>>
>> I don't understand this reasoning. Earlier in the thread we discussed
>> how the sources recommending these conventions also mention that if we 
>> have
>> a practical reason or problem with that convention to do something
>> differently. We received complaints on this name about collisions so I
>> don't follow how we should still follow the convention.
>>
>>
>>> Plugin writers specify natural keys.  Also, by introducing '_'
>>> prefix (or any prefix) means a table could have both 'ID' and '_ID' 
>>> columns
>>> which is especially confusing since the 'ID' column would not be the
>>> primary key.
>>>
>>
>> We have two concepts here that are similar, so I think that problem
>> is mostly unrelated to this decision. For example, if we leave the names
>> as

[Pulp-dev] Ideas for the plugin template

[Austin Macdonald]

I've recently updated the plugin_template to work with the latest
master (3.0). [0] The template handles almost all of the bootstrapping
work necessary to write a new plugin, so it is valuable to keep it up to
date. Given human nature, it's likely that the plugin_template will tend
to fall behind as it did recently. I have some ideas to save time while
keeping the template current and useful.

1) Move the plugin writer docs [1] into the plugin_template repository
- Leave a (very) high level overview in the core docs with a link to
  the template docs.
- Plugin writer docs PRs would only go to one place, and it would
  be easier keep the docs in line with the code.
- Narrative docs in the template would explain what needs to be
  done generally, linking to the modules.
- Specific instructions would live in the code modules alongside
  basic working code, and additional commented out code
  to demonstrate and explain more complex behaviors.

 2) Add pulp_smash tests for basic functionality of a bootstrapped plugin.
 - Run these tests as a check on pulpcore and template PRs
 - Ensure that discoverability works
 - Fail with breaking Plugin API changes
 - If the test uses pulp_smash, it would include a base set of
   integration tests for every new plugin.

My reasoning is that no matter what changes we make to pulpcore,
we need to keep the plugin writer docs updated. Doing this in the
template will provide value for plugin writers, and will inform pulpcore
developers when it needs to be updated.

[0]: https://github.com/pulp/plugin_template/pull/9
[1]: https://github.com/pulp/pulp/tree/master/docs/plugins/plugin-writer
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

[Daniel Alley]

>
> 1) If we do this, what happens when someone uses multiple plugins and both
> of them want to use id as well?  Wouldn't it be better to have the core
> application reserving it and *all* plugins doing some derivative name?
>

One plugin wouldn't affect another since it's namespaced by table - it's
just that since plugin models inherit from core models, plugin fields can
conflict with fields from core and vice-versa.

2) I'd really like to hear more from the actual plugin writers desiring the
> change on if this is a really big deal or just a minor complaint and if it
> is important to them, have them write a story detailing why.  Who is the
> best person for me to ask?  Someone on Satellite?  RPM?  Is someone reading
> this who is effected and could give further details?
>

I don't feel strongly about it.  I understand Jeff's opposition and I also
understand that the fact that two independent workshop attendees from the
community ran into the issue means it's a common  tripping point
 for plugin writers.  I don't
feel like it's a serious issue in the long run, but there's definitely some
friction there. Even though it is a convention, it's not one understood
well enough that it prevents plugin writers from being frustrated by it.

I don't think we should drag this conversation out too much longer, but
I'll bring up one new point.  Pulp is unique in the sense that users
subclassing Pulp models and adding their own arbitrary fields is even a
concern in the first place.  Most Django projects simply don't need to care
about this at all.  Does this justify breaking the "common" convention?

I will make one more suggestion.  What about naming "id" -> "uuid"?  This
carries the clear connotation that it is a unique identifier so it is less
likely to be confusing a la "id and _id", and is still less likely to have
a namespace conflict.



On Thu, Jun 14, 2018 at 10:28 AM, Dana Walker  wrote:

> I'm -1 still but I had a few questions.
>
> 1) If we do this, what happens when someone uses multiple plugins and both
> of them want to use id as well?  Wouldn't it be better to have the core
> application reserving it and *all* plugins doing some derivative name?
>
> 2) I'd really like to hear more from the actual plugin writers desiring
> the change on if this is a really big deal or just a minor complaint and if
> it is important to them, have them write a story detailing why.  Who is the
> best person for me to ask?  Someone on Satellite?  RPM?  Is someone reading
> this who is effected and could give further details?
>
> Thanks,
>
> --Dana
>
> Dana Walker
>
> Associate Software Engineer
>
> Red Hat
>
> 
> 
>
> On Thu, Jun 14, 2018 at 9:08 AM, Brian Bouterse 
> wrote:
>
>> Jeff, can you elaborate more on your -1. I want to understand it. I'm
>> struggling to appreciate an "it's a convention" argument without sources
>> like an RFC or similar. I don't believe internet articles are credible
>> sources because any viewpoint can be validated by an internet post.
>>
>> To recap my interests here, it's about being responsive to the community.
>> We ask plugin writers for feedback and from two independent plugin writers
>> (not me) we received feedback that this name wasn't ideal. I want us to be
>> responsive to that. It's not only because I think their technical feedback
>> is legit (albeit small), but also because it's our strategy during the
>> beta/RC of Pulp3 core is to make adjustments based on plugin writer
>> feedback. To receive feedback and choose to not follow the recommendation
>> they suggested feels like not the way I want to interact with plugin
>> writers. This is my main concern with not making a change in this area.
>>
>> All the best,
>> Brian
>>
>>
>> On Wed, Jun 13, 2018 at 10:26 AM, Jeff Ortel  wrote:
>>
>>>
>>>
>>> On 06/12/2018 05:03 PM, David Davis wrote:
>>>
>>> I do think the most compelling case for renaming the field is having
>>> feedback from plugin writers to do so and also the desire to reduce
>>> complexity for plugin writers. Honestly, I am on the fence about renaming
>>> the field.
>>>
>>> Just to clarify, is anyone a hard -1 on renaming id?
>>>
>>>
>>> -1
>>>
>>>
>>>
>>>
>>> David
>>>
>>> On Tue, Jun 12, 2018 at 5:32 PM, Brian Bouterse 
>>> wrote:
>>>


 On Tue, Jun 12, 2018 at 5:11 PM, David Davis 
 wrote:

> On Tue, Jun 12, 2018 at 4:50 PM, Brian Bouterse 
> wrote:
>
>> Silly question, but could we just call our 'id' 'pk' instead? Since
>> that is a fully reserved value in Django for the primary key it seems
>> clearest to just use that? What about that?
>>
>
> Are you recommending we rename the id field to pk in the database? I’m
> not sure if that would work.
>

 I'm wondering if its possible yes. #django says it is but they've been
 wrong before. I haven't had a chance to test it.


>
>
>>
>> On 

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

[Jeff Ortel]

On 06/14/2018 10:37 AM, Daniel Alley wrote:
I will make one more suggestion.  What about naming "id" -> "uuid"?  
This carries the clear connotation that it is a unique identifier so 
it is less likely to be confusing a la "id and _id", and is still less 
likely to have a namespace conflict.


Appreciate the suggestion but this would only be marginally less confusing.

___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

[Simon Baatz]

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

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

[Jeff Ortel]

On 06/14/2018 08:08 AM, Brian Bouterse wrote:
Jeff, can you elaborate more on your -1. I want to understand it. I'm 
struggling to appreciate an "it's a convention" argument without 
sources like an RFC or similar. I don't believe internet articles are 
credible sources because any viewpoint can be validated by an internet 
post.


RFCs typically define standards not conventions. Agreed on internet 
articles being available to support most any viewpoint. FWIW, I didn't 
introduce the aforementioned article.  Conventions are typically 
establish through example.  IMHO, most articles, tutorials, textbooks, 
etc use ID (or TABLE_ID) for the primary key. Also, this convention has 
been applied on /every/ project I have worked on.




To recap my interests here, it's about being responsive to the 
community. We ask plugin writers for feedback and from two independent 
plugin writers (not me) we received feedback that this name wasn't 
ideal. I want us to be responsive to that. It's not only because I 
think their technical feedback is legit (albeit small), but also 
because it's our strategy during the beta/RC of Pulp3 core is to make 
adjustments based on plugin writer feedback. To receive feedback and 
choose to not follow the recommendation they suggested feels like not 
the way I want to interact with plugin writers. This is my main 
concern with not making a change in this area.


I am sensitive to plugin writer requests but changing the name of the 
primary key field for every table in the core because 2 plugin writers 
said that it "wasn't ideal" seems rash.  I'm not convinced that this is 
a correctness concern but rather a minor inconvenience for what seems 
like (so far) a small percentage of plugins.  Plugin writers will always 
need to contend with naming conflicts and I believe the plugin is the 
proper place to resolve them.  I also want to be responsive to feedback 
but I think it's reasonable for the answer to be "no" when the request 
is not in the best interest of the project as a whole.


___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

[Jeff Ortel]

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

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

[Jeff Ortel]

On 06/14/2018 12:19 PM, Jeff Ortel wrote:



On 06/14/2018 10:37 AM, Daniel Alley wrote:
I will make one more suggestion.  What about naming "id" -> "uuid"?  
This carries the clear connotation that it is a unique identifier so 
it is less likely to be confusing a la "id and _id", and is still 
less likely to have a namespace conflict.


Appreciate the suggestion but this would only be marginally less 
confusing.


Reconsidering this suggestion for the reasons you outlined.

___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Ideas for the plugin template

[Bihan Zhang]

+1
I think the plugin_template is very valuable for bootstrapping plugin
development, but we have had issues with keeping it up to date. Creating a
smash test that will enforce this on new PRs make perfect sense to me.



On Thu, Jun 14, 2018 at 11:29 AM, Austin Macdonald 
wrote:

> I've recently updated the plugin_template to work with the latest
> master (3.0). [0] The template handles almost all of the bootstrapping
> work necessary to write a new plugin, so it is valuable to keep it up to
> date. Given human nature, it's likely that the plugin_template will tend
> to fall behind as it did recently. I have some ideas to save time while
> keeping the template current and useful.
>
> 1) Move the plugin writer docs [1] into the plugin_template repository
> - Leave a (very) high level overview in the core docs with a link
> to
>   the template docs.
> - Plugin writer docs PRs would only go to one place, and it would
>   be easier keep the docs in line with the code.
> - Narrative docs in the template would explain what needs to be
>   done generally, linking to the modules.
> - Specific instructions would live in the code modules alongside
>   basic working code, and additional commented out code
>   to demonstrate and explain more complex behaviors.
>
>  2) Add pulp_smash tests for basic functionality of a bootstrapped plugin.
>  - Run these tests as a check on pulpcore and template PRs
>  - Ensure that discoverability works
>  - Fail with breaking Plugin API changes
>  - If the test uses pulp_smash, it would include a base set of
>integration tests for every new plugin.
>
> My reasoning is that no matter what changes we make to pulpcore,
> we need to keep the plugin writer docs updated. Doing this in the
> template will provide value for plugin writers, and will inform pulpcore
> developers when it needs to be updated.
>
> [0]: https://github.com/pulp/plugin_template/pull/9
> [1]: https://github.com/pulp/pulp/tree/master/docs/plugins/plugin-writer
>
>
>
> ___
> 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