David Channon wrote:
I think limited application of aliases would be beneficial but query
substitutions would work in many situations. The current date issue I am not
sure that it is one of them.
In anycase, supporting two parsers will be necessary across actively supported versions.
Yes. The existing .hql package has a long unhealthy life ahead of it. We will need to support it for a long time to come. This will be very costly, I'm afraid.
Can we get some estimate of exactly what we think is going to break here? I can think of
* some aliases * some SQL function calls * Hibernate 1.x-style syntax - foo in class Foo - bar in foo.bars.elements
We might almost be able to replace the hql package with a preprocessor/postprocessor that predigests the query into a form that the new parser can swallow. I don't think this is impossible or even difficult.
We talked a little about a Version 3 where package names get changed to org.hibernate and other items changed as well but the fear/issue was breaking to much existing code. Don't want to do this lightly. Is this step with the new parser and possible changes to the supported syntax a Version 3 option?
As I said, my view is that there is no plan for Hibernate3. I have no intention of breaking any existing code in the forseeable future. The new parser is really going to be needed for Hibernate 2.2, because we need to support EJBQL as well as HQL (HQL2?) ... and we need code reuse across the two query language implementations.
------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
