I'll respond to Chris's question soon, but I want to clear one thing up in this response:
On Sep 29, 2011, at 4:13 AM, Rubén Pérez wrote: <snip> > > 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). > The index does not need to be recreated each time a role is changed. The solr schema contains a column for ACLs, so any time you need to change the roles for an object (e.g. a series), you need to reindex *that* object. In the series example, we have different columns for different kinds of ACLs (can view, can associate recordings with, can manage, etc.), and these are stored in different columns. If we add a new kind of ACL, we'll need a new column, and will need to rebuild the entire index. Josh > 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] > _______________________________________________
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
