From: Steve Waterbury <steve.waterbury@gs...> - 2002-03-02 21:35:42
Jason Hildebrand wrote:
> FYI: I think there may be (at least the beginnings of) a PostgreSQL
> adapter floating around. Someone else can probably send it to you if
> you're interested.
I would be very interested! I am about to begin developing one,
if there isn't one. If anyone else is working on one, please
speak up ... I'd be happy to help!
Stephen C. Waterbury
Code 562, NASA/GSFC
Tripp Lilley <tlilley@...> wrote:
>On 1 Mar 2002, Jason Hildebrand wrote:
>> Performance-wise, MiddleKit may be a bit slower (in terms of the number
>> of queries) than doing your own SQL, but it gives you the data in
>> ready-to-use objects, and saves a lot of development time.
>My anecdotal experience is that MiddleKit is currently wicked slow,
>because it's largely unoptimized, and does not internally make much use of
>the database engine's available performance.
The focus of my short-span attention most recently has been an "XML instance to
relational database" mapping engine, although being able to store instances and
then retrieve them probably doesn't approach MiddleKit's sophistication or
usefulness. The mechanism employed does permit independence at the application
level from the underlying store, and it gives the developer the ability to
describe the database tables which are actually being used; indeed, it's
necessary to describe the tables, but it would also be possible to generate
such descriptions if that were desired - personally, I don't believe too
strongly in machine-generated database schema.
One of the "easy but actually hard" things in writing these kinds of mapping
engines is how to take advantage of SQL features so that access to the database
remains somewhat optimal while the decoding of the results by the engine
remains straightforward. In my more naive days, I once wrote some libraries in
Java which attempted to implement a multivalued data store in a "normal"
relational database (which isn't *so* hard), but it also had to provide support
for the proprietary multivalued database query language - it's not hard to
imagine how the above tradeoff posed significant problems.
>Anyway, back to the original point... What Jason said about the nature of
>the clauses you would typically pass to the fetchObject methods is
>dead-on. They're generic, and you really shouldn't find yourself using
>sub-selects and the like too often, as long as you're normally querying
>based on the state of the objects you're fetching, not "related" objects.
For related material, I would suggest looking at the Enterprise JavaBeans 2.0
specification, particularly the variant of SQL that they use to
describe "finders". Myself, I'll hopefully get round to thinking more seriously
about how querying that is more sophisticated than "primary key lookup" can be
done in my XML-centric view of the world - I wonder if any of the XML querying
specifications are relevant.
Jim Kraai <jkraai@...> wrote:
>Has there been any discussion of using the DB-SIG's DB-API spec as a basis
>for abstracting support for new databases?
There was a fair amount of discussion about this in the last few months, and
recently someone announced the "open sourcing" of some libraries to help with
portability issues (including an SQL parser, I believe).
Get your firstname@... email at http://Nameplanet.com/?su