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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://www.redhat.com/mailman/listinfo/pulp-dev
<https://www.redhat.com/mailman/listinfo/pulp-dev>
_______________________________________________
Pulp-dev mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-dev
