Skip to content

Instantly share code, notes, and snippets.

@erochest

erochest/gist:82b0ee7f4664db483aeb

Created September 2, 2014 18:52
Show Gist options
  • Save erochest/82b0ee7f4664db483aeb to your computer and use it in GitHub Desktop.
Save erochest/82b0ee7f4664db483aeb to your computer and use it in GitHub Desktop.
Download ZIP
Response to issue
Raw
gistfile1.md

Response to issue 99. (See also issue 97).

After reviewing this, implementing this feature a lot more complicated than it appears:

  1. Omeka's access control is too fine-grained to simply add a simple search on a new public/private facet: SolrSearch can index data from multiple types of resources. They can be viewed by users with different roles and levels of access. So access control has to be done using is_allowed on the Omeka/PHP side.

  2. However, it would be better to handle pagination from the Solr side of the equation. That way, we only look at the items that we have to, and we don't need to have the rest cross the network and be parsed by PHP.

    Unfortunately, because of #1, we have to also paginate in Omeka/PHP. We can mitigate this by accessing larger pages than we need to in order to make sure that we get enough to display. If we still don't have enough results visible to the user, we would need to request another block of results, and continue going until we get enough to fill the results page.

    In the pathological case, this could involve requesting the entire result set to find out that there aren't any results visible to the current user.

  3. Actually, it's much worse than this. :) We also display the hit counts for various facet values. Currently, we can also rely on the results that Solr returns for this.

    However, with this change we'd need to count those values on the Omeka/PHP also. This feels to me like it would be brittle, and it would have very poor performance, because it would require us to download all the results for every search.

We could mitigate this for the most common use case by having Solr handle pagination and facet counts for users who aren't logged in and are viewing the public site.

However, this would add a lot of fairly complicated code for the less-frequent use case of searches by logged-in users.

On the flip side of this, Omeka's built-in search has gotten better.

Based on these reasons, we're going to table this feature. I don't want to rule it out completely, but we'd need some pretty compelling use cases in order to move it forward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment