I don't know which service was exactly, but I came across one which had a SORL index AND persisted the data in the DB also. So, everything is in the DB, when the service starts the SORL is repopulated and the searches and stuff are always done in SOLR. I'm not sure if this is the best approach or just the simplest, so that the feature could make it into this release.
Anyway, I share your concerns regarding the fact that the SOLR index has to be recreated anytime we change a role (because SOLR does not understand those 'prefixes', and the roles/tenants are "textually" appended to the names). Regards Rubén 2011/9/29 <[email protected]> > 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 > > 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? > > 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? > > We have this notion that you can run a workflow to update ACLs (which will > rebuild the SOLR index I assume), 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. > > 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.) > > 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. > > (Also, multitenancy is just prepending a tenant namespace to each role? Or > am I > trivializing this?) > > Chris > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ >
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
