[Pulp-dev] Partially constructed data in the DB
daviddavis at redhat.com
Wed Dec 13 19:42:19 UTC 2017
Thanks for answering my questions. I agree on not using an “is_” prefix and
Your suggestion of “valid” sounds fine. Maybe some other options: finished,
On Wed, Dec 13, 2017 at 2:15 PM, Jeff Ortel <jortel at redhat.com> wrote:
> On 12/13/2017 12:46 PM, David Davis wrote:
> A few questions. First, what is meant by incomplete? I’m assuming it
> refers to a version in the process of being created or one that was not
> successfully created?
> Also, what’s the motivation behind storing this information? Is there
> something in Pulp that needs to know this or is this so that the user can
> There may be others but an importer needs to be passed the new version so
> it can add/remove content. It needs to exist in the DB so that it can
> add/remove content in separate transaction(s).
> Lastly, I imagine that a task will be associated with the creation of a
> version. Does knowing its state not suffice for determining if a version is
> IMHO, absolutely not. That is not what tasks records in the DB are for.
> Completed task records can be deleted at any time.
> On Wed, Dec 13, 2017 at 12:16 PM, Jeff Ortel <jortel at redhat.com> wrote:
>> There has been discussion on IRC about a matter related to versioned
>> repositories that needs to be broadened. It dealt with situations whereby
>> a new repository version exists in the DB in an incomplete state. The
>> incomplete state exists because conceptually a repository version includes
>> both the version record itself and all of the DB records that associate
>> content. For several reasons, the entire version cannot be constructed in
>> the DB in a single DB transaction. The problem of *Incomplete State* is
>> not unique to repository versions. It applies to publications as well. I
>> would like to discuss and decide on a standard approach to resolving this
>> throughout the data model.
>> The IRC discussion (as related to me) suggested we use a common approach
>> of having a field in the DB that indicates this state. This seems
>> reasonable to me. As noted, it's a common approach. Thoughts?
>> Assume we did use a field, let's discuss name. It's my understanding
>> that a field named *is_visible* or just *visible* was discussed. I
>> would argue two things. 1) the is_ prefix is redundant to the fact it's a
>> boolean field and we have not used this convention anywhere else in the
>> model. 2) Historically, the term *"visible"* has strong ties to user
>> interfaces and is used to mask fields or records from being displayed to
>> users. I propose we use a more appropriate field name. Perhaps
>> *"valid"*. Thoughts?
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
> Pulp-dev mailing list
> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev