> > 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 <jor...@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@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