On Mon, 2004-04-12 at 00:16, C. Michael Pilato wrote:
> Having read Glenn's document in full in the past, I don't recall
> feeling that it's size was not warranted by the scope of the problem.
Well, the size wasn't my only criticism; I felt like it wandered a lot.
I often had trouble telling when it was talking about the API-level
vtable or about the FSP-level vtable within the baseline FSAP, and there
were a lot of personal comments which tended to draw my attention
astray.
At any rate, I feel I've absorbed it now. My comments:
* Assuming we have an API-level vtable, the general method presented
in the document (with separate vtables for FS objects, transaction
objects, and root objects) seems fine.
* I'm having trouble fitting the FSP abstraction together with the
"Don't fall in love with a physical schema" sentiment expressed in
<http://www.contactor.se/~dast/svn/archive-2004-03/1664.shtml>. The
FSP-level abstraction allows some flexibility in the physical
representation, but does assume a particular set of tables. (This is
not an area I'm heavily invested in, since I'm not interested in working
on alternate DB implementations, but I'm still curious.) Also, the FSP
abstraction does not appear to have pools in its vtable calls. That's
consistent with the current FS code, but seems like a good thing to fix.
* I'm a little concerned about the long-term implications of this
paragraph:
Roundtrips kill performance. [...] In a SQL DBMS every call to
the DB creates considerable overhead. Iÿm not picking on those
methods. Iÿm just pointing out that many things being done
procedurally in the current FS will be faster if they can be
done in a stored procedure or in ´mega¡ queries. Also, if a lot
of interim data is being processed, even temp tables solutions
beat application based procedural solutions in many cases.
The implication here is that the ideal point of divergence for an SQL
implementation might be at a *higher* level than the ideal point of
divergence for libsvn_fs_fs; for while fs_fs wants to reuse all of the
DAG logic in tree.c, an SQL implementation might want to use stored
procedures or caching tables to minimize round trips.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 12 23:51:56 2004