Hi James,
I’m finding the web DBA functionality of BaseX more and more useful but one thing I really miss from the GUI is the display of the number of results in the top right corner. Many times when I’m running a quick query I want to know how many results there are and see at least an example of the results (as often the full set is too long to be displayed). I know I could add count() round the query and run it again but I’m lazy. :)
Yes, this sounds like a useful extension! And I also agree it's not quite obvious how to implement this best with the current architecture.
In fact, the cleanest solution would be to run all queries twice: After having evaluating the query, a second call could be sent to the server that computes the number of results. This could be done by introducing a new util:query() function, which wraps the xquery:eval() call with fn:count() and does not use fn:serialize(). Obviously, this function only makes sense with non-updating queries, but as the editor forces the user to choose between read-only and updating queries, we don't put much effort into that.
In various cases, the count may take much longer than the actual query evaluation, which is stopped after a maximum amount of bytes has been serialized. A simple (artificial) example query for that is:
count((1 to 100000000) ! <a/>)
However, if the count is always triggered after the original query, it simply means that the number of results will be displayed some time after the query result, or (if it really takes too long) interrupted after the timeout. And if a new query is triggered in-between, the result of the counting query could be ignored.
What’s the best way of getting the count though? The naive solution is to run each query twice, once to get the count and once to get the results but that seems less than ideal. I think there’s something with caching of queries that may help. Is that how it’s done in the GUI?
The GUI code for computing and visualizing the results is pretty complex, as it includes all kinds of optimizations to speed up processing. The query results will first be stored in a value and only serialized in a second step inside the Result View (if currently visible) . We could indeed try something similar, but I assume it would take quite some time to get it robust and fast enough.
Any pointers gratefully received and of course I’ll share any code back to the project.
Always looking forward, thanks, Christian