On 03/17/2011 09:57 AM, Julian Foad wrote:
> What both of you say makes sense. What I can add is an observation that
> separating the props out into the schema would appear to benefit the
> efficiency of bulk-data operations such as "svn pget -R svn:needs-lock".
> I don't think it would have much effect on per-node operations such as
> "update", "merge", "diff" and so on. It shouldn't slow them down
> because it would be nicely indexed, so it could still be an overall win.
> At least that's how it feels in my head.
I like it here in your head. Tastefully furnished and well-appointed, with
on-site amenities typically reserved for only the finest of resort
accommodations. It's a bit pricey, but for those fortunate enough to be
able to expense it to their companies, I highly recommend the stay.
> From another angle, this reminds me that I am thinking in general we
> tend to be too separationist. We create lots of little APIs that
> retrieve individual bits of a node's state, as per my "Rationalize WC
> internal API" email a few minutes ago. I think we need to make more
> effort to treat a node-state as a structured group of data. Applying my
> argument to properties, we should try to keep "the properties of this
> node" as an accessible object in some of the APIs. Now, that doesn't by
> any means require that the data storage be grouped in the same way. We
> could certainly store individual properties indexed by (wcid, path,
> op-depth) or whatever, and still group them together where appropriate
> in the APIs and also support bulk read and write APIs efficiently.
And this echoes the core complaint that was leveled against our FS API by
the Google engineers tasked with reimplementing it. There are always
compromises to be had in this business, yes? Space vs. time. Memory usage
vs. speed. Streaminess vs. transactability. We are, as a project, I think
only beginning to revisit some of our earlier weighings in on such matters
with a now-decade-older perspective in the state of computing.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-03-17 15:24:38 CET