[gentle-devel] RE: Query stuff

[Joseph W. <jw...@te...>]

Morten,
=20
The more I look at the rendering, the more I think that it should be =
done basically how it was started with the abstract SqlRenderer class.
=20
When you use QuickGraph or the visitor pattern in general you can choose =
from a number of different visiting algorithms, but they are all generic =
and all assume you only want to visit each node once.
=20
A problem you have with QuickGraph is context.  If you are visiting a =
field, you need to know if it is the first field or the last field( =
which is important for rendering commas in the right place).  While you =
can manage state and context in your IRenderer implementation this can =
get messy and much more complicated than the simple but effective design =
layed out earlier.
=20
This is made worse when you start dealing with Insert and Update =
queries.  I'll never understand why SQL has two different ways of =
assigning name=3Dvalue pairs - one for inserts and one for updates.  =
(field1, field2) values (value1, value2)  vs. set field1=3Dvalue1, =
field2=3Dvalue2.  Since we are creating parameterized queries where the =
parameter name matches the field name, then you have to run through the =
field list twice when you are rendering an insert statement (once for =
the field names and once to generate parameter names).  I am sure there =
are ways around this, but I can't see any simple ones that don't require =
maintaining extra state versus simply writing to a TextWriter.
=20
Even when creating a SQL query from an Object query, I don't think I =
will want to just visit every node in order.
=20
Basically, if we were to use QuickGraph or even the visitor pattern, it =
doesn't fit, but it does add a fair amount of complexity.
=20
The simplest approach seems to be an abstract base class that renders =
"standard sql" and can be overriden where necessary for each DB.  I =
think this approach lends itself the best to re-use and easy =
implementation.
=20
Any peice can be overriden and the logic in any one method is simple.  =
So it should even be easy for each DB class to override different =
methods and insert their custom paging logic as well.
=20
Paging is another area where you can't just visit the nodes in order.  =
The logic of when to visit eacb node can change depending on paging and =
which DB you are rendering to or what type of query it is.  So the =
visitor logic needs to be customizabe as well, which it is using an =
overridable abstract SqlRenderer.
=20
Now that I have that worked out, I will be updating the SqlRenderer so =
that it renders "standard sql" soon and let you know so you can =
implement correct DB overrides for each DB.
=20
Thanks,
=20
Joe
=20
________________________________

From: Morten Mertner [mailto:mo...@me...]
Sent: Sat 6/19/2004 3:44 PM
To: Joseph Ward
Subject: Re: Query stuff



Hi Joe,

> <>Sorry, last week got very busy (I had scout camp from Thursday on).=20
> I am back in town now and I will keep working on the query stuff =
again.

My workstation drive just crashed so I've had a busy week reinstalling
myself. I'm still looking forward to seeing something in the repository
though, as a means of following your progress :)

Yours,
Morten