Quick Q: should I be using the tree cache "adapter" for the web/REST cache - given that keys often take the form of a /foo/bar style of path?

What are pros/cons of using the tree cache adapter? (can you get listings of entries based on partial paths etc?)

yes, for REST api - which (by convention mostly) uses paths as keys. so say: server/a/b/c a is cache name, "b/c" is the key string. server/a/b/c/d a is cache name, "b/c/d" is the key string. So with a tree cache, b/c/d would be the hierarchy, and that means we could (if we wanted) do a GET on a/b (a partial path) - and it would return a list of items below in the hierarcy... (which may be folders/elements, not sure how it works exactly in tree cache)

- think like how JCR maps to URLs, very similar to that. That could be useful for managing content... without tree cache, we can still do it, by indexing the key values (knowing they are paths) and then returning the items without bothering infinispan etc..

but if its not really something that is needed (ie no need to think of it as a hierarchy other then cachename/key) then it is overkill (and a performance issue, like you say).

Hope that makes sense. On Mon, Dec 21, 2009 at 9:57 PM, Manik Surtani <manik(a)jboss.org&gt; wrote: > > On 21 Dec 2009, at 09:22, Michael Neale wrote: > >> Quick Q: should I be using the tree cache "adapter" for the web/REST >> cache - given that keys often take the form of a /foo/bar style of >> path? > > Is this for the REST API into Infinispan? If so, the path structure passed in is purely conceptual to the user. E.g., > > http://server/infinispan/cacheName/mykey --> Key "mykey" in cache "cacheName". > http://server/infinispan/cacheName/my/key --> Key "my/key" in cache "cacheName". > > Is there any need for relationships in paths, e.g., to be able to determine that http://server/infinispan/cacheName/my/key is a child of http://server/infinispan/cacheName/my etc? > >> What are pros/cons of using the tree cache adapter? (can you get >> listings of entries based on partial paths etc?) > > The tree adapter will always be slower than the map API. And, when writing, would be O(n) based on how deep the target node is (since parents need to be locked). What do you mean by partial paths? > > Cheers > -- > Manik Surtani > manik(a)jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

not sure what conclusion is? that it is not worth looking into tree cache? For storage purposes, yes, who cares, but its more from a HTTP client point of view. I can see cases where it might be nice to list items in a subtree from a path (but I don't care how it is actually stored). Probably not going to touch this for now anyway... it seems treecache is overkill for something like this. Like you said, the fact they are paths is more for end user convenience and nothing to do with the storage.

On Tue, Dec 22, 2009 at 10:51 PM, Manik Surtani <manik(a)jboss.org&gt; wrote: > > On 22 Dec 2009, at 01:03, Michael Neale wrote: > >> yes, for REST api - which (by convention mostly) uses paths as keys. >> >> so say: >> >> server/a/b/c >> a is cache name, "b/c" is the key string. >> >> server/a/b/c/d >> a is cache name, "b/c/d" is the key string. >> >> So with a tree cache, b/c/d would be the hierarchy, and that means we >> could (if we wanted) do a GET on a/b (a partial path) - and it would >> return a list of items below in the hierarcy... (which may be >> folders/elements, not sure how it works exactly in tree cache) > > There are explicit APIs to get content and child nodes (getData() and getChildren() respectively, on the Node interface below) > > http://docs.jboss.org/infinispan/4.0/apidocs/org/infinispan/tree/Node.html > > So not sure if this helps you. This adapter just mimics the way JBoss Cache worked as a compat layer. > >> - think >> like how JCR maps to URLs, very similar to that. That could be useful >> for managing content... without tree cache, we can still do it, by >> indexing the key values (knowing they are paths) and then returning >> the items without bothering infinispan etc.. > > Could work, have a look at the TreeCache impl for ideas or chunks you may want to reuse. > >> but if its not really something that is needed (ie no need to think of >> it as a hierarchy other then cachename/key) then it is overkill (and a >> performance issue, like you say). > > Personally I don't see the value. The fact that HTTP URLs have path-like structures is irrelevant to data storage. :) > >> >> Hope that makes sense. >> >> >> >> On Mon, Dec 21, 2009 at 9:57 PM, Manik Surtani <manik(a)jboss.org&gt; wrote: >>> >>> On 21 Dec 2009, at 09:22, Michael Neale wrote: >>> >>>> Quick Q: should I be using the tree cache "adapter" for the web/REST >>>> cache - given that keys often take the form of a /foo/bar style of >>>> path? >>> >>> Is this for the REST API into Infinispan? If so, the path structure passed in is purely conceptual to the user. E.g., >>> >>> http://server/infinispan/cacheName/mykey --> Key "mykey" in cache "cacheName". >>> http://server/infinispan/cacheName/my/key --> Key "my/key" in cache "cacheName". >>> >>> Is there any need for relationships in paths, e.g., to be able to determine that http://server/infinispan/cacheName/my/key is a child of http://server/infinispan/cacheName/my etc? >>> >>>> What are pros/cons of using the tree cache adapter? (can you get >>>> listings of entries based on partial paths etc?) >>> >>> The tree adapter will always be slower than the map API. And, when writing, would be O(n) based on how deep the target node is (since parents need to be locked). What do you mean by partial paths? >>> >>> Cheers >>> -- >>> Manik Surtani >>> manik(a)jboss.org >>> Lead, Infinispan >>> Lead, JBoss Cache >>> http://www.infinispan.org >>> http://www.jbosscache.org >>> >>> >>> >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >> >> >> >> -- >> Michael D Neale >> home: www.michaelneale.net >> blog: michaelneale.blogspot.com >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Manik Surtani > manik(a)jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev