Hi Mark!
Thanks for commenting on this, I was hoping for it.
While I can see the use case for sharing Redis data between 2 tools, I must
admit that I find it a bit weird to set the TTL on one tool and store the
entity on another one. It looks to me that if OGM stores the data, it has
to manage also the expiration.
Otherwise you store data from OGM which might expire in a few seconds if
you're not lucky!
Don't you agree?
--
Guillaume
On Mon, Jun 27, 2016 at 3:47 PM, Mark Paluch <mpaluch(a)paluch.biz> wrote:
Hi Guillaume,
TTL preservation behavior originates from Redis’ behavior and is to
preserve interoperability:
http://redis.io/commands/set
Set key to hold the string value. [...] Any previous time to live
associated with the key is discarded on successful SET operation.
Keys written with SET loose their TTL value and the entry is persisted
without any further TTL. Reading and re-applying TTL is to preserve the
expiry.
The general idea behind is to either apply the remaining TTL from the key,
because TTL is not configured in the entity model or to set the configured
TTL from the entity model.
I see it from an integration-perspective in which Hibernate OGM and other
tools share Redis data and so you’re opting-in for features but things are
not broken.
Best regards, Mark
Am 27.06.2016 um 14:43 schrieb Guillaume Smet <guillaume.smet(a)gmail.com>:
Hi,
So, I'm currently working on reducing the number of calls issued to Redis
in OGM as part of OGM-1064.
At the moment, we execute a call to Redis to get the TTL already configured
on an object before saving it. If the TTL is not explicitly configured with
@TTL, we set this TTL again after having stored this entity (see
RedisJsonDialect#storeEntity). Same for associations stored in a different
document.
In fact, this call returns the time remaining before expiration, not the
TTL previously configured, so I find this behavior quite weird. Basically,
we store information which will expire sooner than expected. I can't really
get a use case for this and I don't think we should have an additional call
every time we store an object for a so obscure thing. Do we really expect
people to mess with TTLs of objects stored by OGM without relying on OGM
@TTL management?
IMHO, we should get rid of this call and only deal with TTL when it's
configured via the @TTL annotation.
Thoughts?
--
Guillaume
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev