[Sugar-devel] On datastore object IDs

[Benjamin M. Schwartz]

Eben Eliason wrote:
> 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.

I agree.

> 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 am suggesting that there _always_ be a session object, and that this
object be the Action.  This object may or may not have an associated blob.

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

I am suggesting a model in which the Action of using an Activity is
represented in the datastore by an object representing the session.

>>>>  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.

In this particular case, I'm referring to the case of pushing a Document
to a friend over the network.  I am suggesting that the Document arrives
without any version history, and without any of its Action associations,
and so gets a new Action (whose title is 'Transferred "$NAME" from
"$SENDER"') a new tree_id, and a new version_id ('1').

>>> 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.

I don't see such a big distinction between the data and metadata.  In
fact, Activities whose state is easily represented as key:value pairs can
put their entire state into the metadata, instead of storing it in a blob.

>> 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?

It sounds like you want case 3:

>> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090702/005e1a13/attachment.pgp