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.
