This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Using Beta 7.2 the jpa autocomplete does not seem to work when you have a wrapped line extened by +. IE: @NamedQuery(name = "findByName", query = "select m from Member m WHERE " + "m.active=true and lower(m.username) = :username AND m.group.id = :groupId"), The autocomplete works for the first "SELECT" part, but on the next line it just says 'No suggestions'.
yes, it was implemented to complete within one literal so far, not sure it should be considered as a defect but will try to look if combined from several literals value can be completed also easily.
As it's new feature, it's just limitation - support completion in one literal, also check one more tool and it also support complition withing first literal only. It's easy to imagine case like "S"+"E"+"L"+"CT a fR"+"om"+ And it's completely unclear how to complete this case and if it's really need to be supported if realize split literals completion in general.
It would be very useful to support expressions instead of only literals. Using entity names as constants in jpql provides a much better refactoring support.
regarding literals, see http://netbeans.org/bugzilla/show_bug.cgi?id=216643
*** Bug 220864 has been marked as a duplicate of this bug. ***
Created attachment 126608 [details] multi line queries This is a case that shows split literals in a valid usage that is expected to be supported.
*** Bug 225685 has been marked as a duplicate of this bug. ***
I think this might become a can of worms. I am probably missing something. I would expect a language like JPQL to live within its own file and file type like everything else, but I don't know where that is. We have to wrestle with this unfortunate string concatenation because the way we are expected to write JPQL in one line is unreadable. If we do what we have to do e.g. indenting then there is no formatting support - the editor will destroy it. JPQL is a core technology but how are we supposed to live with this? I am suggesting that JPQL code completion within Java files is split off into a separate module so that people can opt out of it. On complex queries it cannot be used because one cannot write complex queries on one line. To get reasonable support one must even add "\n" to logical lines so that stack traces are readable. Which makes the code in the editor uglier.
it may worth to reevaluate, except issues I mention above to argure it may be hard to create good completion logic for splitted literals it's dependent on 3rd party library and in previous release completion was possible for full line only, if I got it right it may be chnaged in new parser release. regarding own file, I may not got properly, but you can try to create jpql query in jpql editor and put it into your java file after debugging etc.
*** Bug 231925 has been marked as a duplicate of this bug. ***
*** Bug 235222 has been marked as a duplicate of this bug. ***
*** Bug 228316 has been marked as a duplicate of this bug. ***
RE: comment #2: If we're just talking about a concatenation of literals, I doubt it would add much if any complexity and I see no reason why completion should behave any differently. In the example given, the parser should treat things as "SELCT a fRom" (sic) as usual. I disagree strongly with the opinion that it doesn't really need to be supported; JPA lines routinely span multiple lines. I'll also throw in a shameless plug for issue #228319, which would render this moot.
Where is the strategy for a sound JPQL editing workflow in NetBeans? We are still throwing ideas around while we are already deep into the implementation phase. It has been suggested to edit the JPQL in the JPQL editor and subsequently copy the final result into a java source file. I like this idea the most. The JPQL editor would then need functionality to format JPQL and export as concatenated string AND read it back according to options set in the JPQL editor. This would hopefully satisfy the requirements of this bug. I see a good future for this as it would be easier to add enhancements to the JPQL editor. On the other hand, as we can see here, there will always be strong resistance to enhancements of JPQL support in Java files due to the complexities within a Java source code editor. I would suggest that JPQL parsing and code completion is done exclusively in a JPQL editor not in a Java file. The current situation is just a mess and causes all kinds of problems not only this one. See bug 235622 for an excellent example of the law of unintended consequences at work. The parsing of JPQL in java files is done by the validator at deployment - IDE scanning does not mark erroneous JPQL with error badges and will probably never do so because of JPA provider extensions. So there is only limited scope for IDE support in Java files anyway - which is bad economy in light of the associated risks, including the parsing performance impact.
Looking at a number of requests, I can say there is nothing like "deasn't need to be suported", but it was design to complete in one literal, not in multiple, and it will add some complexity. regarding validation vs cc, finally I hope to have tyme at atsrt of next release dev, to move to current hints api, it will allow to disable hints, chnage hints level etc, and it will be independent from cc, but it's another issue.
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss
The issue is still there and reproducible with core-main checkout as of 2016-07-09.