Hi Gunnar,
see my responses in-line.
Best regards, Mark
> Am 28.06.2016 um 12:55 schrieb Gunnar Morling <gun...@hibernate.org>:
>
> 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?
Yeah, I added some code below.
public class Zoo {
@TTL // not sure about value and defaults here, so omitting that right now
long ttl;
}
public updateZoo(){
Zoo zoo = …;
if(zoo.hasZebra()) {
zoo.setTtl(zoo.getTtl() + 100);
}
}
public class Horse {
@TTL // not sure about value and defaults here, so omitting that right now
public long getTtl() {
if(this.closed) {
return 100;
}
return -1;
}
}
>
> 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?
>
Something like that would work nicely. Let’s split that into two annotations as
@TTL should require the TTL and some TTL strategy annotation could specify the
strategy. Seeing the code I even thing that KEEP could have a nice side-effect
with @TTL defined as one could just load and edit an entity without renewing
the TTL.
> --Gunnar
>
>
> 2016-06-27 16:39 GMT+02:00 Mark Paluch <mpal...@paluch.biz
> <mailto:mpal...@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 <sa...@hibernate.org
> > <mailto: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
> > <mailto: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>
> >>> <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
> >>> <mailto: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 <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@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
