Lots of snipage below... I've tried to leave enough context for my
comments to make sense...
On Friday, June 22, 2001, at 12:02 PM, Daniel Rall wrote:
> Eric Dobbs <[EMAIL PROTECTED]> writes:
>
>> Second, I propose that in place of the present database adaptors,
>> we extend the attached Sql.java with database specific subclasses
>> that override methods where their syntaxes differ. So the new
>> database adaptors would inherit all of the methods that are
>> common, and would only have to implement the differences.
>
> Hmm, this is quite a shift, and it won't play nicely with the
> connection pool. We may need to reconsider this part. Also, whatever
> solution is used, it must be clear where the database adaptor hook is
> for integration of external systems. We already have extensive
> documentation describing the current system (which is working just
> fine, unlike Criteria/Criterion).
I have only looked at the database adaptors to see what role they play
in creating the SQL statements. I haven't looked at what role they
play in the connection pool. And I haven't looked at the connection
pool at all. Perhaps my use of "database adaptor" is misguided. With
regard to the creation of SQL statements, what I care about is having
classes that encapsulate the dialect differences of specific databases.
>> Issues:
>>
>> If an installation is using more than one database, then the
>> application code would have to know when to use which database
>> adaptor. Less than ideal. I haven't given a lot of thought to
>> this problem, but one idea is to try to handle the mapping in the
>> factory -- rather than asking the factory specifically for
>> ORACLE, you might pass the factory a token which tells the
>> factory something about the context in which the SQL will be
>> used, and let it chose the appropriate adaptor based on the
>> context. I'm wide open to suggestions.
>
> Currently this is handled via a combination of the ConnectionPool and
> DB (adaptor) classes. This is an excellent design that we shouldn't
> move away from--it's only the query formation that's less than ideal.
Is it possible to separate the sql creation from the current database
adaptors without breaking their relationship with the connection pool?
Should I find another name to call the classes that will encapsulate
the SQL dialects?
> To do it right, these things take time. :)
You cannot imagine how much or how often I have wished to hear that
phrase. 8^)
> Other than your handling of database adaptors, I'm +1 on your new API.
I'll work on the database adaptor issue.
Thanks for the feedback.
-Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
