Hi Sanne, not sure I follow.
The use case is: Two applications (clients) share one Redis instance. The first (non-OGM) client writes some data and sets an expiry (TTL). The second (OGM) client updates the data stored inside of Redis and preserves the remaining TTL. Note that the first (non-OGM) client wrote an expiry and expects the key to disappear sooner or later. The TTL is not configured in OGM for this use-case because the TTL might be determined somehow dynamic by the first client. Greetings, Mark > Am 27.06.2016 um 15:52 schrieb Sanne Grinovero <sa...@hibernate.org>: > > Hi Mark, > > you wouldn't expect the timeout to be "reset" to some default value > when your code writes to an entity? > > If you could explain the use case, that might help us to understand this. > > Thanks, > Sanne > > On 27 June 2016 at 14:47, Mark Paluch <mpal...@paluch.biz> wrote: >> >> Hi Guillaume, >> >> TTL preservation behavior originates from Redis’ behavior and is to preserve >> interoperability: >> >>> http://redis.io/commands/set <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.s...@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@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
