Caching capabilities in lightblue-client

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Caching capabilities in lightblue-client

paterczm
Do you think it makes sense for the lightblue-client to be able to cache query results? Benefits are quite obvious. The main challenge I see is that the same queries can be expressed differently (e.g. different order of conditions), which would make caching less efficient.

We can also say that caching is the application's responsibility. For example Spring offers a very nice declarative caching implementation [1], which allows transparent caching of method results based on passed parameters (assuming parameters have hashCode and equals implemented properly).

Thoughts?

[1] http://www.codingpedia.org/ama/spring-caching-with-ehcache/
Reply | Threaded
Open this post in threaded view
|

Re: Caching capabilities in lightblue-client

dcrissman
I would agree that caching is the clients responsibility. Is there a particular use case you are running into?
Reply | Threaded
Open this post in threaded view
|

Re: Caching capabilities in lightblue-client

paterczm
This is about a generic query cache, not any particular use case. There is nothing wrong in saying that caching is the client (not to confuse with lightblue-client, used by client ;) responsibility, but providing caching functionality out of the box should increase the number of clients using any cache.
Reply | Threaded
Open this post in threaded view
|

Re: Caching capabilities in lightblue-client

jewzaam
Administrator
I think the difference is only that putting caching in the client makes it easier for users of lightblue to cache results.  It means more capabilities to maintain in lightblue-client though.  As for order of elements etc the query could be passed through something to order consistently.  It wouldn't account for simple things like different operators that mean the same thing ("$eq" vs "=") but it would be close.

Personally I didn't want to maintain a java client for lightblue, it grew because of need.  Given the spring library you noted earlier and probably others out there, it seems it could be relatively easy for clients to add caching.

So, I just come back to making caching easier as the only reason to add it, and I'm not sure that's really a good thing.  Caching the wrong thing or caching something too long can be worse than bad performance..
Reply | Threaded
Open this post in threaded view
|

Re: Caching capabilities in lightblue-client

paterczm
Enabling caching would require explicit action from developer, so I don't think it would increase the risk of bad usage. Yes, putting caching in the client would be (only?) to make it easier for users to use it. An example from AngularJS:

   $http.get('/service/foo?get=1', { cache: true}).success(function(results) {
      // do something with results
   });

A simple principle, but useful and easy to use. I'm thinking about something similar for lightblue java client.