Eric Dobbs <[EMAIL PROTECTED]> writes:
> I think I'm finally getting somewhere interesting.
[snipped API...]
> All of the above are essentially convenience methods that wrap
> three or four workhorse methods. So the implementation is
> shared. And additional methods like these are fairly easy to
> add.
I like it.
> 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).
> Also, if you look at the code, I think you will agree that it
> would be fairly easy for someone to modify the adaptor for their
> database (or subclass it, as the case may be) and then add
> methods for their stored procedures, or unique functionalities
> (like Oracle's "connect by" clause).
Interesting...
> Forth, about backward compatibility... I think we should develop
> this separately from the existing Criteria, SqlExpression, etc.
> Once we have a functional base to work from, and some adaptors
> for specific databases, we start to change the implementation of
> the existing code to utilize these methods. In parallel with
> that I would like to overload methods in BasePeer that would
> accept sql fragments in place of the Criteria object where
> appropriate, eventually deprecating the use of Criteria.
This should definitely be developed separate from Criteria. +1 on the
eventual deprecation of Criteria. It would help to have a conversion
program available which will parse code that uses Criteria and convert
into the new equivalent. But one step at a time. =)
> 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.
> I'm working with Strings, a lot, which could present a
> performance problem. I've tried to follow the example in
> StringStackBuffer for pre-sizing StringBuffers in the worker
> methods, but it's hard to get around the fact that Object has a
> toString and does not have a toStringBuffer.
Can't do much better in Java than following the StringStackBuffer
example.
> Should this project be in commons?
Likely not.
> Obviously, it's still not complete. 8^)
To do it right, these things take time. :)
> I tried to apply a flyweight pattern to Fedor's model of breaking
> the SQL down to very granular objects. Sounded good at first:
> convenience of objects without the overhead of instantiating many
> objects for every SQL statement. As I tried to externalize the
> state from those objects, I found myself writing into those
> objects exactly the methods I proposed in my last reply to Fedor,
> but inside flyweight objects. That seemed like a nice
> compromise, but basically just added overhead. I had to make an
> extra method call to get the flyweight object, and then call the
> method inside the flyweight.
>
> So I rewrote it into it's present form. And then I realized that
> this code and the database adaptors could be treated as
> flyweights, 'cos they're not really storing any state. That
> brought in the idea of using a factory and the factory service.
I like the API you presented. It's clean, narrow, and can be
implemented efficiently.
> I mention all of this mostly to enrich discussion on the
> proposal. I'm still open to other ideas, but I think the
> solution I'm presenting is better than the other options I've
> considered.
Other than your handling of database adaptors, I'm +1 on your new API.
Daniel Rall
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
