Scott/Paul,
Thanks guys!
Randy
Scott Wilson wrote:
On 14 May 2010, at 12:17, Paul Sharples wrote:
On 14/05/2010 11:44, Scott Wilson wrote:
On 14 May 2010, at 11:35, Paul Sharples wrote:
On 14/05/2010 08:24, Scott Wilson wrote:
On 14 May 2010, at 00:18, Randy Watler wrote:
Hey Gang,
I noticed that SharedData and Participant are keyed back to the Widget using
the GUID field. This is in contrast to the preponderance of the persistent data
which is keyed to Widget via its object id. I assume there is no objection to
unifying this for all Widget relationships and using the object id. Otherwise,
let me know if the use of GUID for SharedData and Participant was by design and
I missed something along the way. Thanks!
The "sibling" definition for shared data and participants uses the rule of "same
widget in same context". Now this could be keyed on Widget ID rather than Widget GUID if we
can guarantee the stability of the ID - I think keying on GUID is simply because this should always
be the same, even if the widget is unloaded and then reinstalled and gets another ID. However I
don't think this should really be a problem, so keying on the ID should be fine.
Unless Paul can think of a reason why we still need to do it this way?
Other than Scotts comments, I can't see any problem with using the id instead.
However, as a point of note, an earlier version of wookie didn't have the GUID
field in the shareddata table at least. I originally envisaged shareddata to
be associated with widgetinstances, rather than an actual widget. Do we need
to have either widgetid/guid in there at all? You can get both of those values
from widgetinstance.getWidget().
Wouldn't you then have to have multiple copies of the same data row in the
table? After all a shareddata entry is shared by multiple instances.
shareddata is shared by multiple instances but accessed by each of those
instances using the shareddatakey which should result on the operation being
carried out on the same record. (or so I thought)
widgetinstance1 has a shareddatakey of "mykey", but the userid is "fred". It adds a new shareddata
tuple: dkey ="chatlog" (shareddatakey="mykey")
widgetinstance2 has a shareddatakey of "mykey", but the userid is "bob". It also wants to add a new
shareddata tuple: dkey="chatlog", but should first check to see if there already exists an entry in shared data with
the values dkey="chatlog" and shareddatakey="mykey". If its already there, then widgetinstance2 appends to
that tuple.
So each widgetinstance uses the dkey and shareddatakey to lookup the correct
record. I guess shareddatakey & dkey in shareddata should be a
compound/composite key.
Its possible I'm getting confused now.
Looking in the code, there are only a couple of cases where
shareddata.widgetguid are used:
1. In the Wave API, for collecting together all the shareddata instances
related to a single instance to push a state update to that instance, e.g:
for(SharedData data :
SharedData.findSharedDataForInstance(widgetInstance)){
state.put(data.getDkey(), data.getDvalue());
}
return state;
2. In the Clone() method of the REST API for cloning a state model
3. In the Destroy() method of the REST API for removing all references to a widget instance (hmm, not sure about that being correct...)
You're correct that shareddatakey+dkey is the composite primary key for
shareddata. Widgetguid is just a handy hook for some special queries, and could
use either the id or guid.
Paul
Randy
