Currently we model the attributes "triageStatus",
"triageStatusChanged", and my favorite, "doAutoTriageOnDateChange" as
a single EIM field. We modeled it this way in order to be able to
atomically apply or discard changes to these attributes as a group.
However, after actually using Chandler it's obvious this was a
mistake because even though two Chandlers might change an event's
triageStatus to the same value (such as "Done"), if the
triageStatusChanged value differs this will register as a conflict.
The conflict UI will say that someone else changed triageStatus to
Done, but so did you, and that will be annoying.
So I have a new EIM model for triage which should prevent
triageStatusChanged and doAutoTriageOnDateChange from participating
in conflicts, but I want to make sure I understand the requirements
first. I'll run through an example:
1) An event on the server has a triageStatus of Later
2) Chandler A changes it to Now and updates it on the server
3) Chandler B has locally changed it to Done and does a sync
4) Chandler B will see a conflict between their change (Done) and
what's on the server (Now)
I think it's safe to say the above example is expected behavior. On
to another example:
1) An event on the server has a triageStatus of Later
2) Chandler A changes it to Now and updates it on the server
3) Chandler B has also locally changed it to Now and does a sync
Is there a conflict? Chandler A and Chandler B presumably have
different values for triageStatusChanged; should those values cause a
conflict?
If the answer is Yes, I don't know what to do. :-) If the answer
is No, then here is a model which should work:
Instead of combining "triageStatus", "triageStatusChanged", and
"doAutoTriageOnDateChange" into a single field, the ItemRecord will
have a triageStatus field which is simply an integer containing a
code such as 100 for Now, 200 for Later, and 300 for Done. We can
add a new TriageRecord which has 3 fields: "uuid",
"triageStatusChanged", and "doAutoTriageOnDateChange" (although I'll
probably just call the field "auto"). All fields of the new record
will be key fields so that records of this type are never in
conflict, just like we did for the ModifiedByRecord. It's not as
clear to me what the translator should do when it receives a
TriageRecord though: should it always apply the TSC and doAuto
values, or should it only apply an inbound TSC if the TSC is more
recent (larger negative number?) than what the item currently has.
Ugh, I think I just need to get on the phone with someone, probably
Bryan, and hammer this out.
I gave the Cosmo team a heads up that an EIM schema change is coming
and they didn't get too mad. :-)
~morgen
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
