On Sep 24, 2009, at 9:11 PM, Greg Stein wrote:
> On Thu, Sep 24, 2009 at 20:21, Hyrum K. Wright
> <hyrum_at_hyrumwright.org> wrote:
>> On Sep 24, 2009, at 5:04 PM, Bert Huijben wrote:
>>
>>> Author: rhuijben
>>> Date: Thu Sep 24 14:04:20 2009
>>> New Revision: 39580
>>>
>>> Log:
>>> Update the WC metadata schema to reflect the new idea about storing
>>> conflicts. We will store all conflicts in a TEXT field of the
>>> ACTUAL_NODE
>>> table serialialized via the skel api.
>>
>> Forgive me for being dense, but why are we using skels here? Why
>> should we worry about serialization when a structured format (which
>> is
>> what SQL is meant to be) does that for us?
>
> Same reason we serialize properties: we probably don't need the pieces
> of data available for manipulation/query individually, and a skel can
> be easier to deal with when 1:N mappings exist (one node, N prop
> conflicts) and we want *all* N all the time.
>
> We *could* have a prop_conflict_data for that last 1:N element, but we
> still don't really need separable access to the other data items. (or,
> at least that's my impression)
Ah, yes, this thought occurred to me after I sent the above mail. We
do have a public API which returns three booleans, set depending upon
whether or not there is a prop, text, or tree conflict. Implementing
this API becomes less straightforward when we have to fetch all the
conflicts all the time (as opposed to "select count(*) from
conflict_victim where kind = 'foo' and wc_id = ... and local_relpath
= ..."), but it remains to be seen how this API is used and whether or
not its callers need updating.
Or the code could have churned so much in the last week that the above
concern is a non-issue. :)
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2400222
Received on 2009-09-25 15:13:37 CEST