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

Re: apr_dbd vs. direct sqlite (was Re: searchable revprops?)

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2007-05-15 22:21:26 CEST

On 5/15/07, Eric Gillespie <epg@pretzelnet.org> wrote:
> "Ben Collins-Sussman" <sussman@red-bean.com> writes:
>
> > On 5/15/07, C. Michael Pilato <cmpilato@collab.net> wrote:
> >
> > > That's a good observation, Ben. Let's not be guilty of rushing something
> > > under-designed into the codebase, though.
> >
> > Totally agree. I meant, "here's a yummy feature someone could take
> > the time to write a design spec for." :-) Whatever the design may
> > be, I imagine that the implementation will be fairly easy, now that
> > we've got SQL at our disposal.
>
> Speaking of that, should we be using apr_dbd instead of sqlite
> directly? If sqlite doesn't perform well enough for large
> installations (as i suspect), this would make it easier to plugin
> a replacement for all svn's SQL usage in one fell swoop.
>
> As long as we only use sqlite in one place, it's not as much of
> an issue, but if we think we're going to expand our usage, i
> think it makes sense to think about this. Especially before 1.5
> ships and it becomes too late. Or, hmm, i don't know, would
> switching from direct sqlite to apr_dbd in some post-1.5 release
> be a compatibility issue? Still better to think about it sooner
> rather than later...

apr_dbd is rather new (i.e. not in apr-util 0.9.x), and doesn't solve
many of the problems with swapping new db back ends in (i.e. sql
dialect differences), so I'd recommend sticking with raw sqlite unless
there's a pressing reason not to do so.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 15 22:21:37 2007

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.