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.

Am 27.06.2016 um 14:43 schrieb Guillaume Smet <guillaume.smet(a)gmail.com&gt;: 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

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&gt;: 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

Am 27.06.2016 um 16:21 schrieb Guillaume Smet <guillaume.smet(a)gmail.com&gt;: 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 <mailto:mpaluch@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.smet(a)gmail.com <mailto:guillaume.smet@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 <mailto:hibernate-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/hibernate-dev <https://lists.jboss.org/mailman/listinfo/hibernate-dev>

Am 28.06.2016 um 12:55 schrieb Gunnar Morling <gunnar(a)hibernate.org&gt;: Hi, > [...] The TTL is not configured in OGM for this use-case because the TTL might be determined somehow dynamic by the first client. Yes, but this kind of issue is the crux when integrating different applications through the database. If you can't avoid it, you at least should use the same configurations within all the applications. Just as e.g. column names, all applications syncing on one DB must be using the same ones. > So maybe we could address the TTL issue in a different way that is more user-friendly and provide properties within an entity annotated with @TTL That sounds interesting, could you describe in some more details how such feature would be used? I could imagine some kind of "state-based" TTL calculation, leaving it to the entity to return the TTL to use from some annotated property. Is that what you had in mind?

Or maybe we could have some strategy of sort which determines the behaviour for OGM writes: @Entity @TTL(value = 7, unit = TimeUnit.DAYS, strategy = REFRESH) public class Zoo { ... } TtlStrategy.REFRESH would update the value to the given one for each write. Another value such as KEEP would maintain the existing one to implement the alternative behaviour. RERESH would be the default. On the downside, to support no TTL being given via OGM at all and being able to work with KEEP, we'd have to make value and unit optional. Maybe a separate annotation then?

--Gunnar 2016-06-27 16:39 GMT+02:00 Mark Paluch <mpaluch(a)paluch.biz <mailto:mpaluch@paluch.biz>>: 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 <sanne(a)hibernate.org <mailto:sanne@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 <mpaluch(a)paluch.biz <mailto:mpaluch@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> <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.smet(a)gmail.com <mailto:guillaume.smet@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 <mailto:hibernate-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev <https://lists.jboss.org/mailman/listinfo/hibernate-dev> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev <https://lists.jboss.org/mailman/listinfo/hibernate-dev> _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/hibernate-dev <https://lists.jboss.org/mailman/listinfo/hibernate-dev>