[Pulp-dev] Partially constructed data in the DB

Brian Bouterse bbouters at redhat.com
Wed Dec 13 19:54:19 UTC 2017


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?

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.

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.

-Brian

On Wed, Dec 13, 2017 at 2:42 PM, David Davis <daviddavis at redhat.com> wrote:

> 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 <jortel at redhat.com> 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 <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
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> 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/c66e49f5/attachment.htm>


More information about the Pulp-dev mailing list