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