> -----Original Message----- > From: Philip Martin [mailto:philip.mar...@wandisco.com] > Sent: donderdag 19 augustus 2010 3:39 > To: Greg Stein > Cc: Bert Huijben; dev@subversion.apache.org; phi...@apache.org > Subject: Re: svn commit: r986865 - /subversion/trunk/notes/wc-ng/node- > data > > Greg Stein <gst...@gmail.com> writes: > > > But that said, there is an argument for combining all three conceptual > > tables into one. Is that was you guys were suggesting? > > Yes. The tables are so similar. For example, base_node's > repos_id/repos_relpath/revnum and the working_node's > copyfrom_id/copyfrom_relpath/copyfrom_revnum and both a sort of > "repos-node-rev". For op_depth 0 the repos-node-rev is always set, > there is pristine content and it's the same node in the repository and > wc. For other op_depth the repos-node-rev is optional, copies have > it, adds don't; but when it exists it means much the same: the node > has pristine content. op_depth tells us whether the repos-node-rev is > a copy or a base and that's exactly what op_depth is for. > > Now op_depth 0 can be split out into a separate base_node table, our > current model, but during our meeting we were wondering if that is > necessary or useful. > > We do have to have all fields at all op_depth, and some are not always > valid. dav_cache only applies to op_depth 0, translated_size only > applies the the greatest op_depth for any local_relpath, etc.; but > most of the fields are common. Even dav_cache might apply to higher > levels, perhaps it could be useful for the copyfrom?
How would this handle deleted nodes in one layer (then some overlays) and then calling _read_children(). I think that would become a union/select over multiple layers? We already had some performance issues there in the past and I hope this only makes this query easier. (SELECT DISTINCT name where parent_relpath=? or something) Before this new idea I expected that we didn't have to query the NODE_DATA if you were just querying _read_info() for kind and status. So for those two most common fields I didn't expect any slowdown over the current model. With moving everything in one table we will need the sqlite index for optimization in a few more cases to keep the same speed. (I think SQLite can handle this for us as one of the nice features of using a real database, but nevertheless, I think we should try to verify this before moving everything into one table) Bert