-
Notifications
You must be signed in to change notification settings - Fork 210
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sorting not working for search API #8
Comments
Earlier version of this https://tickets.corp.opscode.com/browse/OC-11238 |
@sean-horn the version of Manage used should not be an issue. Manage will not implement sorting on the client side until it's working on the server. Ideally we would implement these together at the same time. |
In combination with https://github.com/chef/chef-manage-issues/issues/12 this is the number one customer Feature/Fix request. |
At this point, we're going to have to classify this as a feature and not a bug. The server-side sorting feature has been non-functional since sometime in 2010. When this feature was working, the Chef Server was storing the flattened-and-expanded node object data as individual fields within Solr. The number of fields in Solr quickly expanded to over a milliion based on all the key combinations of all the nodes on the server, and search times suffered drastically. Solr behaves best when the number of fields is kept low (at the time benchmark comparisons were going up to 32 fields). To improve (really, unbreak) the search performance on large Chef Server installs, we combined all of the flatten-and-expanded node keys into a Since all of the node-related keys are merged into the content field in Solr, we can't actually tell Solr what fields to sort on when returning query results. Without significant changes and / or new APIs in the Chef Server, we have two options (neither of them particularly great) for obtaining sorted search results: server-side and client-side: server-side: This would be fine for small result sets, but for large installs this quickly balloons the memory usage of the Chef Server. client-side: |
Perhaps we should open an issue with the client to remove the sort parameter in the DSL methods and the options in the CLI tool, so people don't get confused. |
👍 to that, @stevendanna. Also paging @smith to this thread. |
I'd be interested to hear what kind of things we're talking about here. Since we're talking about the way the data is stored and queried, "significant" sounds pretty significant.
Would we be able to mitigate or make feasible any of this by exploring some kind of SAX-like JSON streaming parser (to keep the memory usage low) or some of the postgres functions for manipulating JSON on the way out of the server?
We could figure out ways to allow sorting only after all rows had been loaded in memory, but that wouldn't survive a page refresh and would present tricky UI design challenges.
I'm ok with that, but as long as there are search results displayed in a table with headings, users will click the headings and want it to sort when the headings are clicked, because that's what people expect. They will not stop asking for this feature so long as things are in a table with headings. Would it be possible to have some kind of preconfigured white-list of key/paths where we make sorting possible and only allow those (configured in chef-server.rb)? Just throwing out ideas at this point. I'm open to not supporting sorting, but at this point I think the user who is caused the most pain by this might be support, since they have to keep fielding requests about it. |
In 2015, unsorted lists are not acceptable in my opinion. Look at the products we use on a daily basics, how many give us unsorted lists? |
If we limited what you could sort on, could we potentially use PostgreSQL cursors (http://www.postgresql.org/docs/9.2/static/plpgsql-cursors.html) to do sorted, paginated results without blowing up memory? |
I don't really know how much relevance it has to a realistic solution to this problem, but I'd like to note that https://github.com/jcreedcmu/psql-gunzip-test is a proof-of-concept that does allow ordering-by and postgresql-indexing on the json fields that are stored gzipped in serialized_object columns. e.g. I can get |
Storing the json data gzipped is kind of silly anyway, because PostgreSQL will already compress column values automatically. |
@petere I think I was just reading about this yesterday. Does this page describe the compression you are talking about? http://www.postgresql.org/docs/9.2/static/storage-toast.html |
@petere Very much agree. The compression is an artifact from when we supported mysql as well. We wanted to maintain a sql model containing the least common denominator between the two, and it was easier at the time to own the compression ourselves than to model the differences between how postgres and mysql managed things. It doesn't make much sense now. Going forward we should stop compressing things on the erlang side; it doesn't add any value and closes off cool things like JSONB. |
I opened up #225 to separately address erlang-side compression, since that can be done independently of whatever solution we arrive at here. |
Related question: Putting search results aside, what's the difficulty of sorting results on the /nodes, /cookbooks, /roles, /environments, etc. endpoints? |
@charlesjohnson since they only return ids (aside from cookbooks, which have the most recent version I think), I'm guessing you would just need to add an |
+1 for this bug. |
What does it even mean to sort the results server-side on, e.g. /nodes, if what's being returned is unconditionally a JSON map of all the nodes? I thought the issue of sorting was meaningful for the search endpoint because it's paginated. |
is there any way I can help to move this forward? |
Any work around for this? Its very painful to search for every role you want to add. |
Please make the chef server web UI lists sortable |
The "sort" parameter in the search API is not working. Also reported in CHEF-2121.
This is causing Chef Manage(chef/chef#2279) and 'knife search' commands to display unsorted lists. Here are some "knife search" results to show the issue:
Same unsorted list returned with these commands:
The text was updated successfully, but these errors were encountered: