2:43 p.m.
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
3:47 p.m.
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>:
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
3:52 p.m.
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> 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>:
>
> 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
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:39 p.m.
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>:
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> 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>:
>>
>> 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
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
12:55 p.m.
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>:
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>:
>
> 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> 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>:
>>>
>>> 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
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
2:23 p.m.
Hi Gunnar,
see my responses in-line.
Best regards, Mark
Am 28.06.2016 um 12:55 schrieb Gunnar Morling
<gunnar(a)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 <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>
3:04 p.m.
I might be dumb but I can't figure out a use case where you would want an
external app to set a TTL and OGM to manipulate the same objects while
keeping the TTL originally set. It really looks weird to me.
Anyway, if it's really a use case, I think Gunnar's proposal does fit and
will allow to remove these useless pttl calls.
As for the dynamic TTL based on a property/method, let's keep it for
another day.
Mark, do you wish to make a proposal on the REFRESH/KEEP thing or should I
take it from there?
Btw, as far as I'm concerned, I would use @TTL because even if you want to
use the KEEP option, you probably would want to set a TTL if the entity
doesn't exist yet? What I would do is: if there is already a TTL for this
object, keep it, if not use the TTL defined in @TTL. But as I didn't
understand the original use case, I wouldn't bet on it :).
--
Guillaume
4:21 p.m.
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
4:56 p.m.
There are many views on this problem. Let me borrow an example from Hibernate ORM:
Databases were be shared amongst multiple applications and clients (I’m aware that this
pattern is discouraged for many reasons) on several of my earlier projects. A lot of these
projects used Hibernate ORM to access the data. There was one master application that had
the authority over several tables. Other clients than the master applications were able to
perform modifications to data and they configured just a minimal subset of entities and
columns, sometimes even different from the configuration of the master application.
That was required to ensure interoperability between applications and the database. I
fully understand the weirdness of these scenarios, especially because in some cases there
was no one who really knew how it worked in total. The openness in Hibernate allowed us to
use Hibernate and still do our work because Hibernated did not break things. It went out
of our way where we needed and served us where required.
That’s also my way of thinking here. I’d be rather surprised if someone accesses data and
because the framework takes ownership over particular aspects of data I’m no longer able
to integrate with other clients by operating on the same data store.
I’ve the feeling that there might be the same number of good arguments for both
strategies: Preserving the TTL or applying the configured TTL.
Let’s diverge into TTL in MongoDB: TTL in MongoDB is handled by an index
(expireAfterSeconds) and documents. The actual expiry is set within a document.
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. I’m not familiar enough with the
ORM and OGM core to estimate the complexity of such an feature. With @TTL properties we
could give the user the control over the TTL. Then we just need to decide what to do if
there’s no @TTL property inside an entity and we’re back at the question what to do in the
default case.
Am 27.06.2016 um 16:21 schrieb Guillaume Smet
<guillaume.smet(a)gmail.com>:
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?
That’s the nature of NoSQL data stores I guess.
--
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>
2859
days inactive
2860
days old
8 comments
4 participants
participants (4)
-
Guillaume Smet -
Gunnar Morling -
Mark Paluch -
Sanne Grinovero