That would help a bit, as any caching we add can improve things. This particular feed is a good candidate for static caching, which is very easy to add. Anonymous and logged-in users should access it through a different URL though, since they get different results. This could be as simple as an arbitrary appendage to the URI (?anon=true vs ?anon=false). Also, the front-page "Recent activity" widget should probably change so it doesn't poll the server every 15 seconds.
This doesn't leave Cassandra off the hook though... still want to see those answers! :) -chris On Thu, 19 Jul 2012 11:29:06 +0200, Nicolaas Matthijs <[email protected]> wrote: > I'm afraid I won't be able to help with the Cassandra question. > > However, I did want to point out that there is no need for these > results and queries to be real-time. For this particular feed, > anonymous users only need to see things that are public, and logged in > users only need to see things that are public or visible to logged in > users. I think that means that the results can be published and > cached, and re-published from time to time. > > Not sure if this changes anything, but maybe it can be helpful. > > Kind regards, > Nicolaas > > > On 19 Jul 2012, at 01:02, Chris Tweney wrote: > >> I just submitted a pull request for KERN-3036 [1] that seemed way >> harder >> than it should be thanks to our Solr-plus-KV architecture. I'd like to >> challenge those who know a lot about Cassandra to see if that platform >> would make it easier to fix this issue. >> >> Capsule version: To support /var/search/activity/all.json, we need a >> query that returns all the activities that point to nodes to which I >> have read permission. The read permission inheres in the nodes >> themselves, not in the activities (which just inherit their parents' >> permissions). >> >> In a relational model it's an easy problem: Just a three-table join >> from >> Activity to Node to Permission. >> >> In Solr, the fix was less straightforward. Solr joins (documented at >> [2]) are not fully equivalent to SQL joins. In particular, they're >> more >> like inner queries than like true SQL joins. Also, joins between two >> different types of documents must be made on fields that the two >> document types do NOT share. In other words the foreign key has to >> have >> a different name from the key it points to. These constraints made it >> tricky, but I did finally find the right Solr syntax for this search: >> >> q=resourceType[* TO *]&fq={!join from=path >> to=activitysource}(readers:anonymous OR readers:everyone) >> >> Does Cassandra make this case any easier? If so, show me how! >> >> -chris >> >> [1] https://jira.sakaiproject.org/browse/KERN-3036 >> >> [2] http://wiki.apache.org/solr/Join >> _______________________________________________ >> oae-dev mailing list >> [email protected] >> http://collab.sakaiproject.org/mailman/listinfo/oae-dev _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
