On Saturday, August 4, 2001, at 12:29  AM, Fedor Karpelevitch wrote:

>> I also agree that *structure* is important for the
>> Criteria object, but I don't agree that this is
>> critical functionality for creating SQL.
>
> I insist that it is. Look at the current Peer code. Without the ability 
> to
> figure out what columns, tables and such the criteria contains it would 
> be
> impossible for Peers to accomplish many things they do, such as fetching
> joins.

Peers are tightly bound to the Criteria object.
Anything that replaces Criteria will require changes to
the Peer code anyway.  I'm confident that the Peers can
be made to support the SQL system I propose, but it
will take a while for me to prove it with real code.


>> Seems like a lot of work to just build a string.  So I
>> decided to tackle the string-building problem more
>> directly.
>
> Again, building a string is not a big deal. If that was the only 
> function I
> would prolly just write straight sql...

Writing SQL directly would be great if it didn't lock
your code into a single database solution.


> another good reason not to use Strings is strong typing. I know that for
> fetching rows I need a condition so sig would be 
> xxxPeer.doSelect(Condition
> cond) so you cannot pass in entire query or your dog's name or you 
> would get
> compile-time error versus getting a runtime failure because of 
> incorrect SQL.
>
> //BTW: today, for another matter I was named Fedor "Typesafe" 
> Karpelevitch .
> This seems to be right to the point :-)

Not sure I can argue with you here, but I'll give it
some thought.  Type checking is good, and might be good
for the SQL solution.


>> With Criteria and other models the programmer creates a
>> tree of objects in their code to represent the grammar
>> of a SQL statement.  That tree of objects is strikingly
>> similar to parse trees (unless I'm completely mistaken
>> about parse trees 8^).
>
> ok, i see
>
> the reason for creating the trees is that Peers need to manipulate 
> them. They
> cannot do it with strings...

Peers as they exist right now definitely need to
manipulate the Criteria object.  As I said before, I
am confident that the peers can be made to work with
strings (or StringBuffers) instead of Criteria.


Fedor, it is clear that you don't like anything I have
proposed so far.  You haven't budged from your original
proposal at all.  I am going to keep going in my
current direction until I can prove in code that it's a
better solution, or until I am convinced it's not.

Please accept my sincere thanks for all the feedback
you have given, even if you still don't like where I'm
going.

-Eric

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

Reply via email to