[Sugar-devel] On datastore object IDs

[Eben Eliason]

On Thu, Jul 2, 2009 at 3:23 PM, Benjamin M.
Schwartz<bmschwar at fas.harvard.edu> wrote:
> Eben Eliason wrote:
>> Anyway, the subtler point here, just for the sake of stating it
>> outright, is that sending an object to someone and sharing that
>> activity with them are (as they should be) quite different actions. In
>> the former case, they just get the object, and can use it as the
>> starting point for their own modifications, with their own history. In
>> the latter case, they will wind up with an object with the same
>> tree_id (and even version_id, for that matter) as the person who
>> shared it.
>
> If version_id is meant to be preserved across shared sessions, then:
>
> 1.  If I join someone else's shared session after it has been created,
> then I might have version "1.1.1" but no previous version.  If I join
> again later, I might also get "1.1.1.3.2", with a gap in my version history.

Yes, this is possible, and I believe it's acceptable. Differential
storage could pose a problem, but from an experience standpoint I
think this is OK.

> 2. Even weirder, if two people produce new versions independently, they
> will both get the same version_id, despite being entirely distinct objects.
>
> I conclude that either (a) version_id`s cannot be preserved or (b)
> version_id`s must be selected so as to be unique (e.g. based on large
> random numbers).

I thought about this. In fact, I almost suggested in my last email
that they should be random/unique. However, I second-guessed that
assumption based on the following scenario (assume all objects
referenced share the same tree_id):

1. Kids A and B collaborate in v_2 (assume v_1 existed previously)
2. Kids A and B separate
3. Kid A modifies v_2 to produce v_3(a)
4. Kid B modifies v_2 to produce v_3(b)
5. Kids A and B come back together
6. Kid A opens v_3(a)

At this point, kid B could open either v_1, v_2, or v_3(b) If kid B
opens v_1 or v_2, I would NOT expect a merge attempt to happen; we
should allow two different versions of the same object to be opened
(so as to copy a small piece from an old version, for instance). If
kid B opens v_3(b), I would expect a merge to be attempted.

Having said all that, it now seems clear to me that what I'm actually
concerned with is doing merges when v_x and v_y are the "most recent"
versions belonging to the individual who resumes them. No matter how
many new versions kids A and B make, a merge should be attempted
between their newest versions, but only their newest versions. So, in
the end, what matters is not (as I foolishly thought when I began to
write this scenario) that we only want to merge when the version
numbers are the same. Silly me.

Unique version numbers are good.

I'm glad I laid this out, though, because I think it's crucial to
getting the merge stuff you want to work on done right. Do you agree
with my thought process here?

Eben


>>> Ok.  Maybe we need some new vocabulary like "read/write metadata" vs.
>>> "read-only metadata".  Action<->Document references would have to live in
>>> "read-only" metadata, managed by the Datastore.
>>
>> That seems like a reasonable split, but I'm not sure it falls on the
>> same line as versioned/un-versioned.
>
> I agree; they are not the same.
>
>