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