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.
|Summary:||JPA Autocomplete fails on wrapped line|
|Component:||Persistence||Assignee:||Sergey Petrov <sj-nb>|
|Severity:||normal||CC:||athompson, bht, ecerichter, matsa, misterm|
|Issue Type:||ENHANCEMENT||Exception Reporter:|
|Attachments:||multi line queries|
Description ender01 2012-05-24 12:46:07 UTC
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'.
Comment 1 Sergey Petrov 2012-05-24 21:42:24 UTC
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.
Comment 2 Sergey Petrov 2012-05-25 10:54:32 UTC
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.
Comment 3 atr_23 2012-08-10 09:57:26 UTC
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.
Comment 4 Sergey Petrov 2012-08-10 10:34:14 UTC
regarding literals, see http://netbeans.org/bugzilla/show_bug.cgi?id=216643
Comment 5 Sergey Petrov 2012-10-26 08:32:33 UTC
*** Bug 220864 has been marked as a duplicate of this bug. ***
Comment 6 ecerichter 2012-10-26 10:11:38 UTC
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.
Comment 7 bht 2013-02-04 07:58:49 UTC
*** Bug 225685 has been marked as a duplicate of this bug. ***
Comment 8 bht 2013-02-04 08:12:08 UTC
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.
Comment 9 Sergey Petrov 2013-02-04 11:00:43 UTC
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.
Comment 10 Sergey Petrov 2013-06-27 12:05:58 UTC
*** Bug 231925 has been marked as a duplicate of this bug. ***
Comment 11 Sergey Petrov 2013-09-04 05:01:41 UTC
*** Bug 235222 has been marked as a duplicate of this bug. ***
Comment 12 Sergey Petrov 2013-09-06 11:37:43 UTC
*** Bug 228316 has been marked as a duplicate of this bug. ***
Comment 13 athompson 2013-09-07 03:49:50 UTC
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.
Comment 14 bht 2013-09-07 04:31:58 UTC
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.
Comment 15 Sergey Petrov 2013-09-07 06:00:48 UTC
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.
Comment 16 Martin Balin 2016-07-07 08:53:51 UTC
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
Comment 17 matthias42 2016-07-09 20:20:37 UTC
The issue is still there and reproducible with core-main checkout as of 2016-07-09.