[Pulp-dev] Partially constructed data in the DB

[Jeff Ortel]

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 
> <mailto: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 <mailto:Pulp-dev at redhat.com>
>     https://www.redhat.com/mailman/listinfo/pulp-dev
>     <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/ec54307b/attachment.htm>