<div dir="ltr">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?<div><br></div><div>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?</div><div><br></div><div>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?</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Dec 13, 2017 at 12:16 PM, Jeff Ortel <span dir="ltr"><<a href="mailto:jortel@redhat.com" target="_blank">jortel@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <p>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 <i>Incomplete State</i>
      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.  <br>
    </p>
    <p>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?</p>
    <p>Assume we did use a field, let's discuss name.  It's my
      understanding that a field named <i>is_visible</i> or just <i>visible</i>
      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 <i>"visible"</i> 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 <i>"valid"</i>. 
      Thoughts?<br>
    </p>
  </div>

<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>