gora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apostolis Giannakidis <ap.giannaki...@gmail.com>
Subject Re: GSoC: Apache Gora
Date Sun, 16 Mar 2014 12:39:10 GMT
Sergio,

Thank you for your interest in this.

To my understanding, there are potentially 2 approaches here:
1) Create a Gora Datastore using Ehcache. This is the purpose of the
GORA-13.
2) Create a caching mechanism that is transparent to the applications and
can work irrespective of the backend Gora Datastore. This is the purpose of
the proposal that I filled (GORA-295).

It seems to me that you already have a solid understanding of the 2nd
approach. However, in my proposal (GORA-295), I proposed to take the
caching a bit further by making the caching mechanism flexible enough so
that it allows the Gora developers to use the Cache provider of their
choice. In other words, they should not be restricted to just Ehcache. As
this is just a proposal, you may deviate from GORA-295 and define your own
goals for this project.

I think that both are reasonable approaches and both would contribute
nicely to the Gora framework.



On Sun, Mar 16, 2014 at 4:37 AM, Sergio Esteves <sroesteves@gmail.com>wrote:

> Thanks for the support, Apostolis.
>
> Can you share a bit of your envisage regarding this issue?
>
> The cache module would not be used explicitly by applications, right?
> Applications will continue using the DataStore API and caching would be
> transparent to them. A cache, irrespective of its granularity (simply
> storing database tuples based on queries or key value objects), should be
> able to cope with all forms of data models (for instance it might be
> difficult/inadequate to store query results in a cache that just provides a
> key/value interface)?
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message