On 5/30/2012 6:29 PM, Adam Heath wrote:
On 05/30/2012 12:22 PM, Adrian Crum wrote:
I need to reacquaint myself with the entity engine code. I was
thinking the visitor pattern could be used to construct the SQL string
instead of the complicated if-then-else code spread across a number of
classes. We could use different visitors for different databases.
Yes, that was my original thought. However, I don't think it's that
simple anymore. I've got a much better understanding of the entity
system since I wrote the visitor stuff.
I'd actually like to see my generic sql code be used to represent
entitymodel, then add sql<->sql conversion code. I have an xslt that
can read *all* entitymodel.xml and convert it to entitymodel.sql, or
entitymodel.java. I used the former to verify that my sql parsing was
featureful enough.
You lost me. How will this look when it is finished? Will the entity
model XML files be replaced with SQL files?
No. I just used the xslt to verify that the actual sql parsing code,
and the built-up object graph, were capable of representing everything
mentioned in entitymodel.xml.
Also, I was wondering if we could add some timing metrics to the
entity engine. Maybe keep an average query time per entity, and
throw
an exception when the average exceeds a configurable threshold. This
would facilitate server overload management.
There is already code that does that, when a query takes a long time.
I don't see any code that does that.
I've seen lines in the log file where queries take too long.
GenericDAO.selectListIteratorByCondition() has an example for that,
but it's not done in select().
Thanks. That code simply logs the time it took to execute a query. I'm
proposing code that will monitor queries and provide feedback to a
server management process.
Sure. The quickly typed example class I gave would help in that.
Yes, that will help. I'm also looking at the Sandstorm (SEDA)
implementation for ideas.
