I'm currently reworking the Content unit to not use MasterDetail ( https://pulp.plan.io/issues/3812). I will make the changes I think I heard on this thread as part of that work. Specifically I plan to have the top level Pulp model that all objects inherit from define: _id, _created, and _updated. Let me know if I should not do this.
re creating mutable vs immutable model types: I don't think it's worth the complexity. On Mon, Aug 13, 2018 at 10:38 AM, Jeff Ortel <[email protected]> wrote: > > > On 08/07/2018 11:47 AM, Jeff Ortel 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 > > > I'm convinced that all tables should have _created. Knowing when > something is created helps fulfill many common use cases and is essential > for troubleshooting. I am open to including _last_updated only on mutable > entities . Depending on the number (ratio) of mutable/immutable entities, > we could support this with either an additional Model class eg: > MutableModel or just add _last_updated on concrete models. Either way, the > column (attribute) needs to be named consistently. > > > _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? > > > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
