Among the other options considered, I forgot to mention Russel
Eden's suggestion about using XML to abstract the SQL. I mostly
like that suggestion. I chose to confine myself to java classes,
particularly because it sounds like Russel already has a working
XML solution. It did lead me to think about using Velocity.
Russel, I would be interested to see your xml representations of
some of the more complex SQL queries I sent in the earlier thread
"Design questions for new query model".
-Eric
On Friday, June 15, 2001, at 05:27 PM, Eric Dobbs wrote:
> Other options considered (this is the special interest part 8^):
>
> After the first round of discussion with Fedor, I tried looking
> at the Object Query Language (OQL) in Castor, 'cos I thought we
> might be reinventing a wheel. (http://www.castor.org/oql.html)
> Along with that I also tried to find more info about parse trees
> and the Interpreter pattern. Our original discussion sounds a
> lot like we're asking developers to create a parse tree by hand.
> All of that seemed too complex for the problem at hand.
>
> I looked at Velocity and especially at the scripts that generate
> the SQL statements for Turbine. That just felt like the wrong
> way to go. I don't have a good reason, just a gut feeling. But
> my intuition is usually pretty good, so I looked elsewhere.
>
> 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 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.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
