an SQL-AST would be useful to have especially without any reference to external frameworks. After have it we can move some responsibility from the HQL-AST (ANTLR depending) to the new SQL-AST (note we already have a sort of SQL-AST used in the HQL-ANTLR parser). So far the most complicated operation, done by dialects, with an SQLString is the pagination stuff for MsSQL2005+. I'm not so sure if we should put some effort in a SQL-AST right now.... mmmm.... perhaps... could it be the first step to remove some other external dependencies ?
On Sun, Feb 6, 2011 at 5:48 PM, Patrick Earl <[email protected]> wrote: > I've heard some negative comments towards SqlString in the past. > What's the long-term vision around this class? That it would be > replaced by a SQL AST? At a conceptual level, I'd like to see > eventual movement from having bits and pieces of things, like a sql > query string, a list of ordinal parameters, a list of named > parameters, moving into self contained classes. For example, there > would something like a SqlQuery class that contains the SQL AST and > any associated parameter information. The same basic idea is > interesting from a Hql perspective. While I'm not under the illusion > that anything like this would happen overnight, I can see that it > would be quite useful to provide already-parsed ASTs to dialects for > specific manipulations, so they don't need to perform their own > parsing in some cases. The ability to manipulate the parameters > alongside the sql itself is very useful. Right now things are too > separate... there are basically two different data flows for > parameters and sql, and IMHO it makes things far more difficult than > it needs be. > > What thoughts are out there in terms of the future in this area? > > Patrick Earl > -- Fabio Maulo
