<div dir="ltr"><div>Defining the field's behaivor a bit more could help us with the name. Will it actually be shown to the user in viewsets and filter results?</div><div><br></div><div>I think the answer should be no, not until it's fully finished. I can't think of a reason why a user would want to see inconsistent content during a sync or publish. There are some downsides when users thinking things are done when they aren't. For instance, the user could mistakenly think the publish is done when its not, trigger package updates, and many machines will still receive the old content because it hasn't been switched over to auto-publish for the expected distribution.</div><div><br></div>Also how is this related to when the 'created_resources' field is set on a Task? I had imagined core would set that at as the last thing it does so that when the user sees it everthing is "consistent" and "live" already.<br><div class="gmail_extra"><br></div><div class="gmail_extra">-Brian</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 13, 2017 at 2:42 PM, David Davis <span dir="ltr"><<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@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 dir="ltr">Thanks for answering my questions. I agree on not using an “is_” prefix and avoiding “visible.” <div><br></div><div>Your suggestion of “valid” sounds fine. Maybe some other options: finished, complete[d], ready.</div><div class="gmail_extra"><span class="m_-4631390161871604727HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_-4631390161871604727m_-7869206984782099237m_4346958101146153224gmail_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></font></span><div><div class="m_-4631390161871604727h5">
<br><div class="gmail_quote">On Wed, Dec 13, 2017 at 2:15 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"><span>
    <p><br>
    </p>
    <br>
    <div class="m_-4631390161871604727m_-7869206984782099237m_4346958101146153224m_1657149683956893774moz-cite-prefix">On 12/13/2017 12:46 PM, David Davis
      wrote:<br>
    </div>
    <blockquote type="cite">
      <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>
    </blockquote>
    <br></span>
    Both.<span><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <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>
    </blockquote>
    <br></span>
    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).<span><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <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>
    </blockquote>
    <br></span>
    IMHO, absolutely not.  That is not what tasks records in the DB are
    for.  Completed task records can be deleted at any time.<span><br>
    <br>
    <blockquote type="cite">
      <div class="gmail_extra"><br clear="all">
        <div>
          <div class="m_-4631390161871604727m_-7869206984782099237m_4346958101146153224m_1657149683956893774gmail_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" target="_blank">Pulp-dev@redhat.com</a><br>
            <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </span></div>

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