On 12/13/2017 01:54 PM, Brian Bouterse wrote:
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.
Agreed.
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.
Agreed.
-Brian
On Wed, Dec 13, 2017 at 2:42 PM, David Davis <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[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] <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] <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] <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
