[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: (SoC) SQL storage option for libsvn_fs_base

From: Edmund Horner <ejrh_at_paradise.net.nz>
Date: 2005-06-15 07:00:59 CEST

C. Michael Pilato wrote:
> Edmund Horner <ejrh@paradise.net.nz> writes:
>
>>...
>
> So, in reviewing your new plan, it strikes me as the same plan that
> Glenn A. Thompson (who likely cometh hence from the ether, but for a
> moment, as I didst utter his name) has been talking about
> on-again-off-again for ... gosh, years, now. Don't get me wrong --
> that's a good thing!

Yup!

>>...
>
> Blah blah yadda yadda ... :-)

What a very astute remark! :-)

>>Deliverables:
>>
>> * Storage layer abstraction in libsvn_fs_base, with the BDB storage option
>> continuing to work as before.
>>
>> * Addition of an SQL storage option, initially storing data in a PostgreSQL
>> database.
>>
>> * SQL functions for exploring the repository in an SQL client.
>
>
> Okey dokey. You forgot one, though:
>
> * Doing all this without noticably negative performance impact on
> existing backends.
>
> [Rest of the proposal trimmed]
>
> I've been recently warned against referring to a generic SQL backend,
> as the flavors of SQL-ready databases differ wildly enough that you
> really need to make special considerations for each one in order to
> harvest the real utility of any of them. So, unless we really think
> we can pull off a generic SQL backend that just works with all SQL
> databases, let's call this one what it is intended to be -- a
> postqresql backend -- shall we? Just trying to eliminate confusion
> and properly set expectations of the receiving public.

Yes, I see. I certainly do plan to avoid any of the PostgreSQL
extensions, or in fact any "standard" SQL features that aren't widely
available, in the libsvn_fs_base work. This probably means going
without user-defined functions, and maybe without views and subselects.
 I think that's easy enough. My main concern for portability is data
types (e.g. BYTEA vs. BLOB vs. etc.).

But since at some point I'll need to do the very database-specific
"#include <postgres_fe.h>"; well, perhaps there will be
database-specific functions for things like creating the repository.

If, in light of the above, you think "PostgreSQL backend" is more
accurate, I'm happy to consider that.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 15 07:02:29 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.