On Thursday 10 May 2001 06:18, you wrote:
> Hi Fedor,
>
> I like the API (or rather the usage) part of nqm.
>
> I have bit of a concern with the implementation though.  We develop mostly
> on Interbase, but mostly we deploy on MySQL or Oracle.  The biggest problem
> I have with current Criteria objects when you do something like:
>
> WHERE a > x AND a < x

:-) I hope you realize that this one will never match? Nevermind, just 
kidding ...

>
> where x is a Date.  Databases require that you give them dates in formats
> that they prescribe.  I fixed it in the Criteria/Criterion objects by
> making use of a PreparedStatement.  This moves the responsibility to the
> JDBC driver.

I remember that and I was thinking of how I can implement this in nqm and I 
think now I know. I'll add the code to the proposal soon.

>
> I'd like to see something similar in nqm.  This can possibly be done by
> adding parameters to the SQLCode interface. Something like this:
>
>     public StringStackBuffer toSQL(DB db, List params);
>
> What do you think?

I do not think this is needed. The params will be obtained from the 
Conditions automatically, so you do not need. It might be handy, though to 
add setValue(Object) method to Comparison so that you can change the value 
without reconstructing the entire Query. This would allow reusing 
Queries/Conditions, but would not be thread-safe. This area definitely needs 
more thought... I have some thought along what you are proposing, but let's 
talk about that later....

>
> We can develop nqm in parallel with Criteria.  All the needs to be done is
> to add the extra methods to the Torque generation classes.  A simple #if
> can determine whether to create the Criteria methods or the nqm methods.

i think they both should be generated and at some point Criteria methods 
should be @deprecated, but still generated.

>
> Just my 2c for a name (I don't really care, but you asked for it)  Advanced
> Query Model = aqumo.

How would you pronounce that? Nice name besides that I have a bit of 
idiosyncrasy for anything with "Advanced" in it's name :-)

Fedor.

>
> ~ Leon
>
> ----- Original Message -----
> From: "Fedor Karpelevitch" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, May 09, 2001 10:02 AM
> Subject: [PROPOSAL] New Query Model
>
> > Hi!
> >
> > here is the deal:
> >
> > Latest activity around Criteria inspired me to try to reimplement the
>
> whole
>
> > idea. I drafted some code which i will check in shortly into
> > proposals/fedor/nqm (the code is not going to compile, it's just draft)
> >
> > The basic idea is to refactor & rename everything to make it more OO,
>
> solve
>
> > problems Criteria has hard time with, make code duplication virtual zero
>
> and
>
> > make it flexible enough to be able to adopt future needs.
> >
> > here is how it breaks down:
> >
> > the select criteria or conditions are all represented by Condition
>
> interface
>
> > (it is similar to current Criterion)
> >
> > the class hierarchy of Conditions looks like this:
> >
> > Condition
> >
> > |----> Comaprison ----> Equal, NotEqual, More, Less etc...
> > |
> > |-----> ComplexCondition ----> And, Or
> >
> > (Yes, I know "ComplexCondition" sounds very medical, go ahead and suggest
>
> a
>
> > better name)
> >
> > so when you need to get SQL like this:
> >
> > WHERE A.B=3 AND A.C>5
> >
> > you'd create the Condition like this:
> >
> > new And().add(new Equal("A.B", 3)).add(new More("A.C", 5);
> >
> > if you need smth more complex (pain with Criteria):
> >
> > WHERE (A.B = 5 and A.C=7) or (A.B=7 and A.C = 15)
> >
> > is done like this:
> >
> > new Or()
> >     .add(new And()
> >              .add(new Equal("A.B", 5))
> >              .add(new Equal("A.C", 7)))
> >     .add(new And()
> >              .add(new Equal("A.B", 7))
> >              .add(new Equal("A.C", 15)));
> >
> >
> > uff... hope you won't have to do that, but at least it does not require
>
> any
>
> > nasty hacks and does not take a lot of extra code....
> >
> > now, that's just WHERE clause, but for a sql query we need a little more
>
> like
>
> > select columns, orderby's etc... For that there is Query object which if
> > functionally is Criteria less Conditions.
> >
> > The inheritance here looks like this:
> >
> > Statement
> >
> > |-----> Query
> > |
> > |-----> Update
> > |
> > |-----> Delete
> >
> > Statement provides common stuff like WHERE and FROM clause.
> > Query also has methods like addSelectColumn, addOrderByColumn etc...
> >
> > So I am asking for comments/ideas/money ... sorry, no money.
> > And I propose this as a replacement to current Criteria and related
>
> classes.
>
> > Appropriate methods should be added to Peers & OM which would take
>
> Condition
>
> > or Query instead of Criteria. At the point when it's fully functional &
> > stable Criteria & corresponding Peer methods would be deprecated and at
>
> some
>
> > point removed.
> >
> > Also couple of smaller points: I think those new classes should go into
>
> their
>
> > own package at least to make it clear where the new stuff is and where is
>
> the
>
> > old one. What do you, guys, think? Also any ideas for the name of the
>
> package
>
> > - the best I could come up with is "nqm", which I do not like...
> >
> > Fedor.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to