Comments

I'd call this a bug in Views, who incorrectly label some backend-specific components as "global". There is no way in the Search API (and, therefore, also in it's Views integration) to retrieve random results.

You could write an extension to the query class which allows this, though, by getting all results and then randomly loading the data of only some of them.

So, this should most probably fixed in Views, by removing the "Global: Random" sort for non-DB backends.

In the patch for schema.xml it would be better to write some documentation rather than link to the website where this is originating from. I am in favour for giving credit, but it should not be the sole documentation since URLs often change, web pages disappear etc.

@MHilliker: are you using Sarnia? I found this too. Adding the same 'search_api_random' field to the Sarnia service's getFieldNames() fixed it--I've committed that to Sarnia, so if you apply the Search API patch from this issue, you should be able to get random sorts.

Here are re-rolled versions (updated comments, patch name format) of the other two patches from earlier in this thread, to Search API and Search API Solr. I find that these allow me to do random sorting with Search API, Search API Views, and Solr.

Ah, the random_* field hasn't been added to search_api_solr's schema.xml file.

Here's an updated patch for search_api_solr that includes the schema.xml snippet from comment #5 above. You'll need to put this updated file in your Solr setup, too. I've included the search_api patch again for the sake of completeness.

I admit, the current patches are very appealing in their simplicity. However, we cannot just introduce a new special sort field that service classes will have to know. Especially since the module is now stable and should therefore keep not backwards-compatible API changes to the absolutely necessary minimum.
The current approach will break all backends except Solr. A better approach would probably be to define a new "search_api_sort_random" feature, or the like, which allows random sorting via an option. Though I admit that the current approach is cleaner and more functional – we sadly can't just add features anymore.

Also, this is definitely a feature request. (And as I'm currently busy solving accumulated bugs of over half a year, it'll probably take a while till I get to it again. Sorry!)

Maybe you could add it in the next version? Or do you have a good example how to do the "feature" the right way?

I don't think we should generally add this as a built-in feature, since some backends might have problems implementing it and it's by no means a must-have for searches. So in my opinion, it should stay an add-on feature in later versions (D8, for example), too.

I don't really have a good example for doing exactly this kind of feature, but it would work like other features – e.g., search_api_mlt, also defined in the Search API Views module. In the add_orderby() method you check whether the index's server supports the feature and, if it does, add the random sort. (Otherwise, you'll probably have to throw an exception or at least display a warning.) Documentation for the feature has to be added in the README.txt file, and also a short description to the handbook page (after the patch was committed, of course). As the format, since the query class doesn't allow arbitrary fields for sorting, I guess you'll have to use an option you pass with the query to override the normal sorting. In my opinion, this should also support having the random sort not as the primary one, so a bit of trickery will probably be necessary there.
(On second thought, since an option would really be complicated, you could also set the sort directly by using the reference returned by &getSort().)

For Solr, just adapt the patch code to the new way of passing the random sort, and add the feature's ID to supportsFeature().

Since this is a feature request and drunkenmonkey made it clear that 7.x-1.x is stable and should not introduce API changes I'm moving this up to the D8 chain.
If someone would be able to change the summary so it represents the ask and why, that'd be awesome.

As long as it doesn't change any APIs but only introduces a new feature, I'd be fine with it. I'm just waiting for a patch that does that. I also don't think it should become a fixed part of the framework in D8 – this isn't useful enough in my opinion to force all backends to (at least try to) support it.

I have the same issue with Elastic Search ; I'm not using a community module as a connector.
How can I solve this ?

Apply the patch from #40 to the Search API, then adapt your service class code to look for sorts on the search_api_random field and add a random sort in that case. As to how to do that with Elastic Search: no idea, search on the web.

Sorry, I don't understand that.
If you aren't using the Search API Solr Search module, this won't work for you, you'd have to implement it again for the backend you're using.
If you are using the Search API Solr Search module, then you need to patch it for this to work.

What about search api random sorting with pager?
In case of a simple view, views_random_seed is used, but in this case it doesn't work.
So, if i have let's say 100 results in 5 pages, there are duplicates.

Hm, you're right, I don't think this will work with a pager. The question would then be whether this is a valid/usual requirement, or randomly sorted views usually don't use a pager anyways. Solving the use case with pager would of course be even more difficult, as you would have to pass the random seed value along to the other pages.

The question then is would this be something that should be added to the module itself or to the views random seed views data module. If the random is supported by the searchapi modules, the random seed module could potentially take care of the paging issue.

Essentially, the difference is where the random is passed. If it is passes as the order we can check for its existence and then if it isn't there add it. This allows for the random seed module to also utilize the orderby function and have the search follow. These patches do not depend on views random seed, but allow for it to be utilized.

Also, I saw that random was in the schema.xml already, so I added the false flag instead of duping the dynamicfieldname.

The previous patch is slightly problematic because of the assumption that order isn't used... The thought is that ASC/DESC do not matter because it is random. It is similar to paging in the sense where if you have an exposed filter and hit the asc/desc filter, then you end up possible duplicates and wouldn't get the same results if you went back to the original filter. I do not think that is an issue, however, let me know.

Soo... what's the status on this ?
I have a view showing results from search api + database search (important: not solr).
I want to randomize the view results.

At this point I cannot get this working. If I use patch from here (not the solr patch because I use db search) and apply global: random to my view, I get: Trying to sort on unknown field search_api_random

If I just use the module views random seed (current or dev version) and sort on 'random seed' I do not get random results (tried setting to random for each user, and change it every 5 minutes. No matter which user or how long I wait, I always get same order instead of random). If I try to apply the patch for views random seed to latest dev version of that module, the patch does not apply correctly.

If anyone has gotten this working (again, i'm not asking about search api with SOLR, i'm asking about search api using database search): please be so kind to tell which modules, versions and patches that are working for you.

#57 with the latest dev version (7.x-1.14+6-dev) does not work for me. PHP error is invoked:"PHP message: PHP Parse error: syntax error, unexpected '*', expecting function (T_FUNCTION) in ../search_api_views/includes/query.inc on line 146"

#50 with latest stable release or dev one does not work as well. No php error, but same on flyke, the "Trying to sort on unknown field search_api_random" error show up.

bisw, which version of api_search (and api_search_db) do you use to make it work ?