[Sugar-devel] On datastore object IDs

[Eben Eliason]

On Thu, Jul 2, 2009 at 1:40 PM, Benjamin M.
Schwartz<bmschwar at fas.harvard.edu> wrote:
> Eben Eliason wrote:
>> Hmm, I think that only objects have titles and user editable metadata
>> (tags/description, etc.). If I open Write, and name that Document in
>> the usual way, that title should be associated with that object. The
>> action will happen to read like:
>>
>> Wrote [My Story]
>>
>> And clicking on the icon next to "My Story" in the action should
>> resume the activity, but the name is actually belonging to the object
>> that the action refers to.
>
> I think sessions can have names too.  If I start an instance of the Chess
> activity and share it with the name "Bedford Middle School Chess Club
> Summer Tournament", then that's the name of the entire session, even if it
> produces multiple Documents or no Documents.

Well, I think that the session is defined by the name provided in the
current name field, regardless of whether or not a Document is
created. In write, that name would refer to the Document object. In
most activities, this name will map to the object. In Record, the name
refers to the "roll of film", which is why I thought there might be a
"session object" in some cases.

I don't think it makes sense to name actions independently of their
activity sessions/objects.

>>> extend it to objects.  However, I think that we can keep this as it
>>> currently is: a metadata attribute like any other.  When I share an object
>>> with you, it may get a new tree_id and a version_id of 1, but it keeps all
>>> its metadata, including its title.
>>
>> This seem fundamentally wrong to me, but perhaps that's because I'm
>> not actually seeing how these 2 problems you bring up are problems.
>
> What seems wrong? What problems?

I thought the two items you had brought previously up were problems
with the idea of associating a single object with multiple actions.

>> Why can't a given Document (tree_id, version_id) be referenced from
>> any number of actions?
>
> It could be.  It just seemed simpler to disallow it.
>
> If editing a Document's metadata produces a new Document, as befitting our
> Copy-on-Write model of versioning, then the process of editing the
> "associated_actions" field produces a new version.  Therefore, every time
> an Action adds a Document to itself, the process of adding the
> back-reference would produce a new version of the Document, so only one
> Action would ever end up referring to one version of the a Document.

Metadata is attached to the version, I believe. I don't think we
should be versioning metadata, so I don't think that it makes sense to
create a new version when changing the metadata.

> If editing a Document's metadata doesn't produce a new Document, then we
> have a hilarious race condition in which  two Activities, both referencing
> the same Document, edit the "associated_actions" field at the same time,
> and one of them ends up getting dropped, producing a corrupted datastore.

This seems like the most plausible case. Really, though, it should be
the Journal (or DS) that's responsible for setting up all of these
references, and not the activities. If activities want to destroy
metadata, they can destroy metadata. But I don't think the race
condition exists if the activities aren't expected to make the
references themselves. Or, can we put a mutex wrapper around metadata
changes?

Eben


> If back-references aren't stored in the Document's metadata, then either
> the datastore has to maintain an inverted index of the references in the
> Actions, or it has to perform an enormously expensive search to find which
> Actions are associated with a given Document.  This adds complexity.

> --Ben
>
>