On Wed, 2010-02-24 at 14:24 +0000, Julian Foad wrote:
> On Mon, 2010-02-22, I (Julian Foad) wrote:
> > Documenting WORKING.presence = 'incomplete'...
>
> [...]
> > My take on this is that we should keep the meanings of the columns
> > orthogonal as much as possible. At the DB schema level, there's no
> > reason why files, dirs and sym-links should not all have props and
> > should not all be able to be incomplete in the sense of not having their
> > props yet. The higher level code might want to avoid ever having
> > incomplete file, or props on a symlink, but that's doesn't reduce the
> > benefit of keeping the schema meanings orthogonal. And there's no reason
> > to have more than one way of representing 'props are unknown'.
> >
> > So let's specify:
> >
> > * presence = 'incomplete' just refers to children when this is a
> > directory. (It does not mean anything about properties.)
> >
> > * 'properties' is NULL if the properties of this node are not (yet)
> > known. ('properties' is an empty skel if there are no properties.)
> >
> > Good?
> [...]
>
> Bert and Greg responded on IRC:
>
> > <Bert> julianf: You can't leave the properties out of incomplete.. The
> > problem is a cancel between open_dir() and close_dir() and between
> > that you can receive some of the property changes (and miss a few of
> > them). When you cancel before the dir_close() you register as
> > incomplete... and when you update again you tell the repository: "I'm
> > incomplete: send me all the children *AND* all the properties"
> >
> > <gstein> julianf: and when Bert used the word "property", he also
> > means "entry properties", which are things like changed_*
> >
> > <Bert> There is no: "Send me all the childrent AND NOT all the
> > properties". (This is editor v1.0 and we had that since far before
> > 1.0)
>
> Let me talk about the regular, versioned properties only, for a moment.
> (The same principles can apply to other properties.)
>
> It is possible to cancel an operation after some properties have been
> received down the wire and before all of them have been received. That
> doesn't mean we need to be able to represent any such state in the DB.
> We could keep it simpler by agreeing that we will only change the stored
> 'properties' column from NULL to a complete list of properties, and
> never attempt to store "some but not all of the properties".
>
> A separate question is whether we require "presence=incomplete" when the
> properties are incomplete. We could instead define "presence=incomplete"
> to mean the children are not all known to be there, and have encoded by
> "properties=NULL" and perhaps also other forms of incompleteness. If we
> do the latter, then an "is this dir incomplete in any way?" API will
> examine both the "presence" column and the "properties" column to answer
> the question.
BTW, we don't want to gratuitously redefine the schema at this point.
The reason I'm considering such changes as this is because it's hard to
understand exactly what can be expected of a node marked as "incomplete"
right now, and we need to know, and I think this would make it simpler.
Maybe the current definition of "incomplete" is simple enough already.
Maybe it means, "the 'kind' column is correct ('directory'), this
directory is present just like the 'normal' presence, and every other
column is unknown if it is NULL but if not NULL then its value is
correct." Or something. If so, that would be OK. Is it so?
- Julian
- Julian
Received on 2010-02-24 15:38:04 CET