On Mar 26, 2012, at 10:10 , Ard Schrijvers wrote: > I am not sure if it would be an issue for oak, but for jr 1 and 2, we > build up jcr session keeping virtual node states in memory : This can > grow too large, and it not easy to limit. Also, since we have many > millions in jcr nodes while only a couple of hundred of thousands of > documents in general, the build in faceted navigation is too cpu > demanding.
so how do users currently "define" such virtual nodes? are they are simply a specialized node type in which one stores the facetting query as a property? or are they ad hoc like SQL2 queries? i can see a use case for both, though the later is more important to me than the former > Another disadvantage imo of our current 'seamless' integration of > exposing faceted navigation over virtual layers, is that you cannot > write to these nodes : Some virtual nodes don't even have a canonical > equivalent. This makes the virtual structure also less obvious to use > fro third parties well thats to be expected from results of aggregation. regards, Lukas Kahwe Smith [email protected]
