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.)
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
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
> We can fix this with a new editor (and a lot of compatibility code..
> and slow IO around that).. Not with just a new working copy
> gstein: *nod* Those are handled via the same API. (And you even
> receive the repository UUID via those properties if I remember
> <gstein> right
Received on 2010-02-24 15:25:03 CET