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.
Created attachment 160433 [details] Screenshot showing missing navigation controls. In NetBeans IDE 8.1 and prior the pager navigation controls (first, prev, next, last) buttons were available on the results toolbar, now only the page size is visible which has been renamed from "Page Size" to "Max. rows". Using the sample Java DB table `CUSTOMER` to produce the attached screenshot of which the count shows 13 records within the table. If this feature is intended to be dropped, please close appropriately. There is a NetCAT test specific to this functionality.
The removal was intentional - basicly paging is broken with SQL as it is today. Please see https://netbeans.org/bugzilla/show_bug.cgi?id=257458 for an discussion.
No problem, thanks for the info. I am curious about the implementation, however. Now that the pagination has been dropped, so too has the `Total Rows` which was often handy without the need for a seperate count statement. This isn't a showstopper, but it is a slight loss in functionality, though I do understand how this could simplify the query. What does strike me as odd though is how now when using the `View Data...` function the generated SQL appends the limit qualifier to the query. This does seem to be a good thing, however; the limit is also specified in the results view. Increasing the limit in the results view does not increase the limit qualifier and likewise increasing the limit on the limit qualifier does not increase the limit on the results view. Due to this it may seem unintuitive for existing users of the IDE.
(In reply to brettryan from comment #2) > Now that the pagination has been dropped, so too has the `Total Rows` which > was often handy without the need for a seperate count statement. This isn't > a showstopper, but it is a slight loss in functionality, though I do > understand how this could simplify the query. Simplyfication was not the reason, but the sub-optimal JDBC driver implementations. To get the row count (and in relation the "page" count), you either have to read the resultset in its entirety, reissue the query as a subquery or use a scrollable resultset and scroll to the end. I won't go into details, but each of these approaches have its drawbacks: - reissuing causes side effects to happen twice (postgresql has no option to detect a stored procedure call) - scrollable resultsets either endanger the server (h2 holds the whole resultset in memory) or the client side (oracle (always) and mysql (if not configured differently) blow the heap - reading the whole resultset is slow + (in case of h2) also causes an OOME on the server side > What does strike me as odd though is how now when using the `View Data...` > function the generated SQL appends the limit qualifier to the query. This > does seem to be a good thing, however; the limit is also specified in the > results view. Increasing the limit in the results view does not increase the > limit qualifier and likewise increasing the limit on the limit qualifier > does not increase the limit on the results view. This is due to the fact, that there are different cases and again driver issues. The easiest way to limit the resident result set size is using (ResultSet#setFetchSize), I think the pattern is clear now: This is at best minimally implemented... So generating select * from X limit X (or the equivalent for each DBMS) is pretty much due to the ways the drivers are implemented. If now only one SQL dialect would exist (or all DBMS would at least a common subset), then we could parse the statement and follow the information. If you are interested, just have a look at the implementation of the generated "limits" implementations, from the top of my head there are 5-6 variants. > Due to this it may seem unintuitive for existing users of the IDE. I agree, but I did not yet come up with a real solution, just with a different balance of ugly. Sorry if this seems to be to negative, but while JDBC in principle is a good standard, there are to many implementations that just suck.
*** Bug 267887 has been marked as a duplicate of this bug. ***