Dain, I could help defining the grammar; unfortunately I'm quite busy this week and on a long sought vacation next week, so you'll have to be patient with me.
The current grammar for JBossQL is not exactly tiny, at least the JavaCC representation is a bit difficult to read due to the way JavaCC grammars model nested expressions. But the things we will have to extend work on a higher syntactical level mostly, as in UPDATE SomeEntity SET SomeField=<expression> which could use similar low level tokens as the existing grammar when doing SELECT ... WHERE SomeField=<expression> We'll also have to decide which features are to be supported; One thing to think about is resultset postprocessing: e.g. in the case of a container iterating over a resultset it _could_ do some postprocessing if there is no adequate sql equivalent of the eql query. Example: SELECT arcsinh(SomeField) ... with a database not supporting that function. This smells like "jet-engine" anyway; I would speak against such postprocessing. One reason is my original wish to support providing the generated sql to any SLSB, and the session would simply pump it into a jdbc driver without any knowledge about need for postprocessing. So are we speaking only of a transformation engine mapping eql/jbossql to db specific sql, as would suffice in the case of UPDATES, where there is no need to postprocess anyway? Regards, Michael Bartmann Dain Sundstrom wrote:
Pete,
To better support complex reporting we just need to add more features to JBossQL select statements (e.g., group by, having, sub queries, and multiple fields in the select clause). I plan on adding most of these features. It would be cool if sun added this stuff, but I find it incredibly unlikely.
What Michael is proposing is adding INSERT, UPDATE, and DELETE statements to JBossQL. This is a very cool idea and I hope he spends some time designing a grammar. Once we have a grammar the implementation should be fairly easy.
-dain
Pete Beck wrote:
Even better would be if Sun added something to the spec. It seems to me that this is a fundamental limitation of CMP 2. No matter how fast the container, it is difficult to see how it would ever be able to do complex reports using CMP without such a feature. Some reports may only return a few records, but might require millions of database records to be processed first. On Fri, 2002-11-08 at 17:08, Dain Sundstrom wrote:That is a super cool idea. This could easily fit into the 4.0 architecture. Do you want to work on proposing a grammar for insert, update, and delete? Once we have a grammar the conversation to sql is simple, and we can easily throw in cache updating logic.
-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd522.html
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
