Hey,
>>>
>>>
>>Glenn Thompson's design calls for modularity at both locations:
>>
>> 1. directly beneath the public FS API, and
>> 2. and the back-end storage interface.
>>
>>There has been some dispute over the necessity of the first of those.
>>I understand Glenn's defense of that position, but think we need a few
>>more knowledgable heads in the circle before making that call.
>>
>>
>>
>>
>
>Can someone refresh my memory as to why we'd need two abstraction
>layers? I've been out of town for a while...
>
>
What a year? :-)
Seriously, Brane have you seen:
http://www.cdrguys.com/subversion/Pluggable3.doc.
It was only a start. Areas written in red were markers.
CMike claims it's not *too* out-of-date. I'm pretty rusty on the FS
code at this point. So I wouldn't know.
>
>
>By the way, before we jump into refactoring and abstracting, there's one
>thing we have to do that should've been done ages ago, only we didn't
>know enough to do it.
>
>And that is, formally document the FS schema.
>
>
>/me waits for the angry shouts to stop
>
>My point is that we never defined a relational schema for the FS. Sure,
>that's because we're not using a relational DB back end. However, the
>time is coming when we _will_. So we now have to define this schema, and
>define how it maps to our BDB implementation, skels and all (that part
>is documented, thank goodness). If nothing else, the various sql
>back-ends will then be able to use the same schema, making it much
>easier to write database-independent query tools.
>
I like the idea of documenting the existing schema. But as far as SQL
schema's go, I prefer a reference schema and a reference SQL
implementation.
Lets not *force* a schema on people. Let's not make it another API.
Nothing sucks worse than having some rocking DB feature that you can't
use because it's required to store data the same for all DBs. Things
that tend to get in the way are "Sequences vs auto incrementing
columns", DB specific isolation implementations, and
(blob/image/external storage) extensions. This doesn't include cool
features like "connect by prior", which only Oracle supports the last I
checked. However it is on MySQL's roadmap. Yes! I'm betting that others
will have it also. My point is: don't fall in love with a physical schema.
>
>We used to have something that Bill Tutt produced, but I hope reality
>isn't as complicated as that...
>
No it's much more complicated than that:-)
If it's the one I saw, it was a logical schema. Physical schemas could
vary quite a bit.
Long live Subversion!
:-)
gat
Received on Wed Mar 31 03:12:55 2004