[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [stellation-res] Database abstraction
|
On Tuesday 13 August 2002 08:58 pm, Dave Shields wrote:
> On Tue, Aug 13, 2002 at 02:06:39PM +0000, Mark C. Chu-Carroll wrote:
> > So... I'm looking at trying to create a database abstraction layer that
> > will work accross Postgres, DB2, Oracle, MySQL/InnoDB, and
> > Firebird.
>
> I don't think it's worth that much effort trying to parameterize DDL
> generation.
Point taken.
I suggest making createRepository() a method in the interface
> AccessPoint (it currently isn't), and letting each implementor provide a
> complete definition.
Two problems with that. First, createRepository is currently a static method
of the access point. The reason for that it because the AccessPoint
requires a fully constructed repository. But it *is* part of the static
interface of the AP class.
Second, as I've said in several messages, the problem isn't just
DDL statements in AccessPoint. There are potentially DDL statements
in many different extensions, and correctly implementing those extensions
means getting the statement right for the database.
But I'll stick with the minimal approach. There's already a basic
lightweight abstraction layer in DBAccessPoint. I'll just pull that out
into an interface, and let extension writers use that. It'll leave the
SQL structure much more explicit, and thus, hopefully less
stupidly overcomplicated.
> The *real* need is to find an open-source relational database that is
> *easy* to install and provides *acceptable* performance. Postgres is easy
> to install, but its performance is lacking. I found DB2 harder to install,
> and sufficiently hard to work with that I don't really have much of a feel
> for what performance we can expect, and DB2 isn't open-source.
I agree here, on all points.
> By "acceptable performance" I mean something able to handle projects up to
> 100K lines of code. In the long run we of course want to handle much larger
> projects, but having this level of performance should suffice to let us
> continue our work.
>
> Having to install a relational database just to play with Stellation as a
> developer is, I think, a real barrier to entry. We need to find a better
> relational database soon.
Provided you mean "developer" as "developer who wants to use
Stellation", I agree completely. If someone wants to work on Stellation,
even just as an extension implementor, they're going to need to be
able to understand and work with the database system that Stellation
uses. On the other hand, for software developers who want to
use Stellation because it's a better SCM system than the
alternatives, dealing with an RDB is a real barrier. We definitely
need to work on simplifying installing and automating the
installation and configuration the RDB.
-Mark
--
Mark Craig Chu-Carroll, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM for Collaboration
*** http://www.eclipse.org/stellation
*** Work Email: mcc@xxxxxxxxxxxxxx ------- Personal Email: markcc@xxxxxxxxxxx