> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: donderdag 19 augustus 2010 3:39
> To: Greg Stein
> Cc: Bert Huijben; dev_at_subversion.apache.org; philip_at_apache.org
> Subject: Re: svn commit: r986865 - /subversion/trunk/notes/wc-ng/node-
> data
>
> Greg Stein <gstein_at_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
Received on 2010-08-19 17:11:50 CEST