Multi-line EJBQL

http://www.jetbrains.net/jira/browse/IDEADEV-9347

When can we expect a first implementation?

Most of our HQL is (obviously) multi-line queries, embedded in Java code.

Nothing definite. In Selena :). And most probably only string constant
concatentation.

Nothing definite. In Selena :). And most probably only string constant
concatentation.

I think string constant concatenation support is all that is needed.
For other types of query text concatenation you need inspection :)

I'm asking because I'd like to give the HQL support more testing, and having
multiline literals support would really make that easy.

Cheers for that. I guess for the moment I'll just write very long single line statements and format them when I'm done.

Or trust your skills at writing syntactically correct ejbQL so you don't need discovery on it ;)
In my experience most if not all complex queries (in whatever language) are constructed on the fly based on input parameters to the method.
It's usually impossible to validate those without running them.
How's an IDE to know each possible execution path through the code that constructs the query and find where there could be a problem if and only if a specific combination of parameters exists?

I was pleasantly surprised to find IntelliJ validating simple queries, but in practice it's little use for those queries where the correctness isn't easily verified by looking at the code.

I'm not trusting IntelliJ to absolve all my worries about a statement, but I'm not a hugely experienced developer so any hints and tips I can get are useful. It's just the same as having the IDE highlight those little syntax errors that creep in so that you can catch them sooner.

Or trust your skills at writing syntactically correct ejbQL so you
don't need discovery on it ;)

Ah, I remember the "I write Java in a plain text editor, a IDE just distracts"
folks. Seems all of them are gone by now. :)

In my experience most if not all complex queries (in whatever
language) are constructed on the fly based on input parameters to the
method.

I don't know if my sample is representative, but a rough guess:
-80% of db interactions are constant/parameterized queries
-15% are "criteria api" based dynamic queries
-5% is "other" (concatenated of something else)

It's usually impossible to validate those without running them.

How's an IDE to know each possible execution path through the code
that constructs the query and find where there could be a problem if
and only if a specific combination of parameters exists?

There is no way to validate/support such things in a robust manner. The same
restriction applies to some more sophisticated Java inspections. In such
cases the tool should back off.

I was pleasantly surprised to find IntelliJ validating simple queries,
but in practice it's little use for those queries where the
correctness isn't easily verified by looking at the code.

I agree, but that is just a small part of the tool support (that I'm after):
-renaming (already present, only aliases, but nice for bigger queries)
-navigation (already present)
-perhaps there are other possible small refactorings/intentions possbile?
-much better editing of embedded query languages (a la IntelliLang)
-quick query execution/testing from within tool
-more? (stuff above of course applies to HQL as well, and someday SQL)

in our current application (50+ SSBs), I think roughly 50% of all queries (SQL, all of them, we don't use Entitybeans) are constructed on the fly from building blocks (which are quite often defined in superclasses or framework level), 10% are plain queries, 40% parameterised queries.

Everything is pulled through a query optimiser afterwards which injects optimisation code and if needed breaks it up into chunks Oracle can handle (Oracle has a restriction of 1000 bind variables, there's a decent chance on many of our queries to go over that).

Everything is pulled through a query optimiser afterwards which
injects optimisation code and if needed breaks it up into chunks
Oracle can handle (Oracle has a restriction of 1000 bind variables,
there's a decent chance on many of our queries to go over that).

Interesting. Is the optimiser a 3rd-party product or something that you developed
in-house?

I'm not sure. I think someone wrote it in-house years ago (well before I joined the company).
At the moment it just sits there and does its job, it's not failed yet since I started working there (the true mark of an effective blackbox component).