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: | Option to disable JPQL Parsing in NamedQueries(jpa hints enable/disable option) | ||
|---|---|---|---|
| Product: | javaee | Reporter: | bht <bht> |
| Component: | Persistence | Assignee: | Sergey Petrov <sj-nb> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | pjiricka |
| Priority: | P2 | ||
| Version: | 7.3 | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
In usual, cost of this feature shouldn't be big, smilar may be said to be able to configure a lot of different features. Code completion may not work here because of issue 216643, and may be fixed in 7.3. jpql parsing should work, but I may recheck. It's still nice to try latest daily to see if reduce in "time consuming calls" really help. Without 216827 and 216053 this issue isn't valid P2 and even may ot be a defect. Its not also clear if it's extremely rare or more common issue, as even with second reporter (with 4Gb memory usage at first) do not have performance hit(at least after all fixes). As an option it can be temporary implemented in a way similar to issue 215725 (with private project property, without special ui) but still much better to find root cause of slowness. Sure, it was my mistake to make it a defect not an enhancement. A property would be nice. I would like a system wide property, but project specific would be good, too. That would help in any future cases where JPQL parsing issues must be analysed. I may need to look at a way to configure hints, some java hints support configure and possibility to be disabled in Editor|Hints. It may be good to implement this approach for jpa hints including jpql validation. While performance of the GUI wrt cursor movement etc. as addressed in bug 216827 has improved, the CPU load remains, and on slow systems it is very taxing. Please refer to bug 221421. Now it is 50 seconds of 100% CPU after saving an entity class with a one line change. This prevents "Run focused test method" execution for 50 seconds. It is this CPU load, apparently caused by the slow NT file system in Windows XP, which is hopefully reduced by turning off JPQL scanning and hints. why do you think it's related? it still good to add support to disable this validation but I found it requires some redsign to new api and may take longer I expect initially. Sorry I don't feel so strong that this is very related. Perhaps to some extent. I am guessing that an additional layer of scanning if that exists adds CPU load and perhaps I/O which is expensive so if we could turn this off that would be good. CPU starvation is my oncern and that is what I am seeing in bug 221421. subj updated to reflect what need to be done. #231332 may help to find out what need to be done to update jpa hints to new api just recheck initial comment, multi line jpql verification was possible before and will be possible after, cc wasn't possible in case of split jpql and isn't possible yet. there was also jpql validation even in case if it's hidden in some constants, unfortunately it will be mossed after migration but it may be ok, literals and summ of literals will be supported anyway and enable/disable will work as for any other hints. mark as fixed, jpql can be disabled, also most others jpa hints can be disabled also (but not all). |
JPQL code in Java files is quoted as string attributes within NamedQuery annotations. This limits useful formatting of larger statements. A common workaround is to concatenate as follows: @NamedQuery(name= CustomerOrder.GET_ALL, query= "select\n" + "object(c)\n" + "from CustomerOrder c\n" ) Apparently JPQL parsing and code completion does not work here. Support of this might come in the future, but it will be at a cost (bugs, CPU load) that some users are not necessarily happy to pay. In other words, it is possible that multiple disadvantages outweigh potential or non-existing benefits depending on the use case. Therefore it would be useful to disable JPQL parsing in the Tools Options dialog, or with a configuration parameter.