On Sep 28, 2011, at 5:22 PM, [email protected] wrote: > Hi, > > In our production environment ACLs have been giving us no end of trouble. > While > specific bugs are soon to be filed (next week by akm I hope), we've seen ACLs > get reset, confusion over the series identified in the UI, and it seems to be > a > pain to change the ACL on the fly (which is something we've had lots of need > to > do). My hope with this email is that someone (Josh??) can enlighten me to how > ACLs work. > > My understanding is pretty naive; that solr includes in it a field that > contains > roles, and that the search query to solr is modified to AND these, this comes > from this file: > > http://opencast.jira.com/svn/MH/trunk/modules/matterhorn-search-service-impl/src/main/java/org/opencastproject/search/impl/solr/SolrRequester.java >
Yes, that's where we query solr for published media packages… those displayed in the engage UI and in RSS/ATOM feeds. > This seems to be an example of early binding; e.g. that if we want to change > the > ACL for a particular file, we need to go back to SOLR and update its esarch > records. > > Am I correct thus far? Yes. This is how we keep the results from the search index efficient. > > I don't know when I should (as a developer) choose to store something in a DB > versus in SOLR. It seems that SOLR for me is ideal for text searching, (e.g. > good with partial matches). Why not store our ACL's in the DB, and filter the > SOLR results? If we were to query for all media packages in solr, then filter by some ACL, the performance would degrade substantially. So we take the performance hit on the few number of writes, and enjoy the fast searching on the many reads. > > We have this notion that you can run a workflow to update ACLs A workflow isn't necessary here. You can use an OSGI Event to broadcast a change in a series, for instance, and have an event handler update search. In fact I added one of these to trunk a couple of months ago. It should already be in 1.3-SNAPSHOT. See SeriesUpdatedEventHandler.java. > (which will > rebuild the SOLR index I assume) No need to rebuild the whole index, just reindex that particular object within the index. > , but this doesn't fit at all with my > conceptualization of what we tend to do. We're much more of the ldap/active > directory mindset; there is some permissions directory that stores > role->series > and this can be rapidly changed on the fly (ideally with a couple of > checkboxes > in a UI, or something similar). The model doesn't seem to be in line at all > with the SOLR method. Right, this is the other approach. Solr work best when all of the information, including "filters" on the data, exist inside the search index itself. > > Can someone help me understand why we are doing it this way? How would I > write > a UI that could change roles associated with series that doesn't have a ton of > work to do in SOLR (my understanding right now is that it would have to find > every mediapackage in the index and inspect whether it is related to the > series > in question then update the media pacakge's role, finally recreating all of > the > indicies. Seems heavy and denormalized.) Right, the series service shouldn't need to know about all of these details. That's why an eventing mechanism works well here. So if you want to update a series, just send an event indicating that the series has changed, and the event handler will update the search index for you, asynchronously. > > Sorry if this is naive or something that's been explained a million times, > just > trying to understand where we are at currently before we start trying to > change > things. > Great questions, no need to apologize. There are tradeoffs here, no matter which way you slice the problem. The choice of using a search index was always to maximize performance and flexibility in finding media, knowing that writes will perform more slowly (and apparently less clearly, too). > (Also, multitenancy is just prepending a tenant namespace to each role? Or > am I > trivializing this?) > I think that was an early idea, but it's not how it was implemented. See SolrIndexManager.setAuthorization() in the trunk to see how this is done in 1.3-SNAPSHOT. Josh _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
