[Pulp-dev] Partially constructed data in the DB

[David Davis]

Thanks for answering my questions. I agree on not using an “is_” prefix and
avoiding “visible.”

Your suggestion of “valid” sounds fine. Maybe some other options: finished,
complete[d], ready.


David

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?
>
>
> Both.
>
>
> 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
> know?
>
>
> 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
> visible/valid?
>
>
> IMHO, absolutely not.  That is not what tasks records in the DB are for.
> Completed task records can be deleted at any time.
>
>
>
> David
>
> 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
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171213/4ef95f27/attachment.htm>