marklogic-community
Tags endpoint: Tags count incorrect
I believe the /v1/tags endpoint is returning the incorrect total number of tags in its responses.
To reproduce:
View More Tags dialog, NOT LOGGED IN, app makes call to endpoint:
search.pageLength = 18
search.sort = 'frequency'
search.start = 1
Result is...
aggregate-result[0]['count'] = 5157 distinct-value = array of 18 objects with _value ('javascript') and frequency (1041)
18 tags displayed per page, so 5157/18 = expect 287 pages to display
(This is what we expect and display in pagination component.)
In reality, can only go to page 51, after that no tags come back from endpoint.
search.pageLength = 18
search.sort = 'frequency'
search.start = 901
last page has 7 results so…
(18 * 50) + 7 = 907 actual results are available, not 5157
Chatted with @grechaw a bit and it turns out this value:
aggregate-result[0]['count']
Is not the total number of tags in the results set, but rather is the sum of all the frequency values for all the tags in the result set.
We need the total number of tags in the results set for pagination. @grechaw is looking into how to offer this.
When we discovered that there's no overt error in this behavior and pushed it, it seems the 'critical' flag is a bit extreme. We also don't know what to do about this bug.
This is one of the higher priority bugs for 8.0-2. Let me know if not feasible.
We at least need a workaround for this one, and should probably file an RFE as well. One proposal is to suppress 'Last' button.
I think suppressing the 'last' button is a good idea -- requires no middle tier action, I don't think. Not sure what to do with this issue -- move to RFE and N/A or backlog?
Leave as bug for now to track: decision for workaround and the effort to implement the workaround.
What about filing an RFE on the APIs for this limitation?
I think our bug is not having a document model that is consistent with the Samplestack specs given what's available in the server. I think the RFE for the server, if there is to be one, is to make it possible to do what we need to do even if we (or the next customer who faces this particular issue) want to stick with the embedded array design of the doc model.
It would seem to me that, theoretically, we could also consider a custom extension which would allow the correct functionality to be delivered reasonably efficiently by at least keeping the code and data on the E-node(s).
As we were discussing this the other day it did ocur to me that if there were simply a document per tag, we could indeed implement this count. There's just another kind of document that would have to be introduced. A medium LOE - 3-4 days I'd say off the cuff.
This may be a duplicate, but any workaround for this is in the browser now -- further work could be done with a revamping of the data model.
If we could do the browser workaround of suppressing the last page option in the tag browser that would be great.
Let's leave this issue here as is for when we actually fix the issue, I've opened #602 to implement a workaround for 1.1.0.