ObjectCache - TTL/TTD
Larry Garfield
was resolved. There are, as I see it, four possible ways to specify the
lifetime of an object being added to the cache:
1) Time To Live, in seconds.
$cache->set($key, $value, 3600);
// Lives for one hour
2) Time To Die, in seconds.
$cache->set($key, $value, 1329359506);
// Lives until this point in time. Whether it expires or is purged then
is implementation dependent.
3) Time To Live, as an object.
$cache->set($key, $value, new DateInterval('1H'));
// Lives for one hour
4) Time To Die, as an object.
$cache->set($key, $value, new DateTime('+1 hour'));
// Lives until this point in time. Whether it expires or is purged then
is implementation dependent.
The advantage of the integer options is that integers are simple.
However, it's also easy to confuse TTL and TTD then, if one is used to a
library that does it the other way around.
The advantage of the object versions is that they're type-specific, so
there can be no confusion about what you need to do. It can even be
specified in the interface. Also, the objects are generally more
flexible than seconds. That introduces some complexity, however.
I guess I don't really have a strong opinion on TTL vs. TDD; I'm just
mindful that as an endian-ness type question half of the people adopting
it are going to be horribly confused either way. :-) The objects would
at least confuse everyone equally, and lead to fewer weird bugs (if
someone passed 3600 when the method is expecting a timestamp, or vice
versa, it won't fail but the cache will not behave as expected).
Thoughts?
--Larry Garfield
Evert Pot
My opinion is that TTL is the most likely what people expect; as this is appears to be the most common third argument.
But not really feeling strong about this either way.
Evert
Paul Dragoonis
DateInterval is a great idea! In 5.3 and 5.4 we've made significant
performance and memory improvements, so overhead of adding another
object into the mix is not a problem at all!
Is there any technical reason why we can't support both? If we decided
to it wouldn't be a problem really.
function set($key, $val, $ttl = null) {
if(is_numeric($ttl)) <-- we know its a timestamp ttl
elseif(instanceof DateInterface) <-- we know its an interval and
can get the TTL from it.
else { throw new InvalidArgumentException('Unsupported TTL Value'); }
}
So... TTL numerical, DateInterval or both.
Any technical problems with this?
Not looking for "I dont like this" its about catering for a mass
adoption of people to adopt a common standard, if we can do it,
there's no reason why we shouldnt.
- Paul.
> --
> You received this message because you are subscribed to the Google Groups "PHP Standards Working Group" group.
> To post to this group, send email to php-st...@googlegroups.com.
> To unsubscribe from this group, send email to php-standard...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/php-standards?hl=en.
>
Robert Hafner
Robert
PS: I'm currently traveling on business, which is why I've been absent- I'll rejoin the conversation in full force on Thursday (I'm sure you're all looking forward to that).
Victor Berchet
Evert Pot
Should we drop supplying the value as an integer? This would then be redundant to me
On Feb 16, 2012, at 3:40 AM, Larry Garfield wrote:
Paul Dragoonis
> I'll expand the proposal to include support for DateInterval, and DateTime. It makes sense..
>
> Should we drop supplying the value as an integer? This would then be redundant to me
I really like integer, but if it's simple to convert timestamp to
DateTime or DateInterval objects then it's not that big a deal.
Evert Pot
On Feb 23, 2012, at 1:00 PM, Paul Dragoonis wrote:
> On Thu, Feb 23, 2012 at 11:36 AM, Evert Pot <ever...@gmail.com> wrote:
>> I'll expand the proposal to include support for DateInterval, and DateTime. It makes sense..
>>
>> Should we drop supplying the value as an integer? This would then be redundant to me
>
> I really like integer, but if it's simple to convert timestamp to
> DateTime or DateInterval objects then it's not that big a deal.
Alternatively it would be possible to treat any value passed in the third argument to the DateTime constructor, this allows
$c->set($key, $value, "+1 hour");
But this is already kind of venturing into the area of over-engineering, so maybe I shouldn't have said that :)
Evert
Paul Dragoonis
An interface can't instantiate DateTime objects from a string.
If the implementors want to do that, then fine, but lets only support DateTime.
Thanks
- Paul.
Evert Pot
> This is implementation again!
>
> An interface can't instantiate DateTime objects from a string.
>
> If the implementors want to do that, then fine, but lets only support DateTime.
Well forcing a argument that must be a valid datetime-formatted string is still considered the interface, and not implementation.
How you parse that string is implemenation specific, although using the DateTime object for it is the most logical choice.
But I digress; Not that important anyway, and wrapping the value in a DateTime or DateInterval object does make more sense to me.
Evert
Jordi Boggiano
>
> If the implementors want to do that, then fine, but lets only support DateTime.
This is not only implementation. The implementor can't do that if the
interface has \DateTime as a type hint. So we need to be clear whether
we want to enforce DateTimes or not. If not, then we allow anything, and
if you want to be able to write code that uses any implementation
interchangeably it means the documentation must describe what values are
to be supported, at least the minimum subset every implementation must
support. If someone wants to support more, fine.
Cheers
--
Jordi Boggiano
@seldaek - http://nelm.io/jordi
Evert Pot
Hmm..
I was actually under the assumption that subclasses, or implementations of interfaces can always safely drop the type-hint, because the liskov principal still applies.
Just tested this, and it indeed does not seem to be the case in PHP.
Bit of a design flaw?
Anyway.. we did talk about supporting both DateTime and DateInterval, so in that case we couldn't use a type-hint anway.
Evert
Paul Dragoonis
I suggest we stick with a solid consistent implementation of DateTime,
that way things are convertible and easy to implement on top of for
whatever use.
Luís Otávio
Evert Pot
> I think that we have to support DateTime only.
> It's more consistent and easy to use.
How is DateInterval inconsistent? Not arguing.. just asking. There are some benefits, because a DateTime is always a fixed point in time, whereas a DateInterval a relative value.
There's also the issue of a type-hint or not.
We can 'demand' support for at least DateTime, even without adding the type hint.
This would allow implementors to add other values as they see fit, or even an options array if they need to.
I don't see a major problem with this, and I think it makes it easier for people to extend the base-line for their own needs. Forcing the DateTime value kind of prevents this a bit.
Evert
Luís Otávio
Evert Pot
> I don't think that DateInterval is inconsistent, but I think that DateTime it's the best choice.
>
> Using DateTime (and I think we should use a type-hint) we're able to do:
>
> $cacheStorage->set('key', array(1, 2, 3), new DateTime("2012-04-01"))
> OR
> $cacheStorage->set('key', array(1, 2, 3), new DateTime("+1 year +3 days -2 hours -3 minutes"))
>
> I know that is just an interface, but the implementation will be simpler.
> Unix timestamp can be used by calling the DateTime::setTimestamp() method, what other values do you think that implementors would like to use?
I'm not arguing against DateTime, I'm arguing for allowing the option to use other formats, if people choose to.
Evert
Paul Dragoonis
Lets put DateTime into the proposal RFC, we can review it later.
function set($key, $val, DateTime $ttl);
- Paul
Luís Otávio
Larry Garfield
That said, I'm fine with going with DateTime since it can emulate
DateInterval more easily than vice versa. I am wary about allowing
implementations to extend it with other types, though.
Suppose LarryCache implements integer fallback (assumes it's a
timestamp), and LuisCode uses it, assuming that it can use integers.
Then someone wants to use LuisCode inside EvertApp, but EvertApp is
already using LukasCache, which only supports the baseline DateTime.
Asplode!
Asplode is not a good thing for interoperability.
--Larry Garfield
On 2/23/12 8:00 AM, Lu�s Ot�vio wrote:
> Evert, I understand your point. I just think that standards should be a
> little strict ;)
>
> Paul, I propose that $ttl can be optional (as mentioned before by
> yourself), so the signature would be:
>
> function set($key, $val, DateTime $ttl = null);
>
> Lu�s
>
> On Thu, Feb 23, 2012 at 11:52 AM, Paul Dragoonis <drag...@gmail.com
> <mailto:drag...@gmail.com>> wrote:
>
> Evert,
>
> Lets put DateTime into the proposal RFC, we can review it later.
>
> function set($key, $val, DateTime $ttl);
>
> - Paul
>
> On Thu, Feb 23, 2012 at 1:50 PM, Evert Pot <ever...@gmail.com
> <mailto:ever...@gmail.com>> wrote:
> > On Feb 23, 2012, at 2:47 PM, Lu�s Ot�vio wrote:
> >
> >> I don't think that DateInterval is inconsistent, but I think
> that DateTime it's the best choice.
> >>
> >> Using DateTime (and I think we should use a type-hint) we're
> able to do:
> >>
> >> $cacheStorage->set('key', array(1, 2, 3), new
> DateTime("2012-04-01"))
> >> OR
> >> $cacheStorage->set('key', array(1, 2, 3), new DateTime("+1 year
> +3 days -2 hours -3 minutes"))
> >>
> >> I know that is just an interface, but the implementation will be
> simpler.
> >> Unix timestamp can be used by calling the
> DateTime::setTimestamp() method, what other values do you think that
> implementors would like to use?
> >
> > I'm not arguing against DateTime, I'm arguing for allowing the
> option to use other formats, if people choose to.
> >
> > Evert
> >
> > --
> > You received this message because you are subscribed to the
> Google Groups "PHP Standards Working Group" group.
> > To post to this group, send email to
> php-st...@googlegroups.com <mailto:php-st...@googlegroups.com>.
> > To unsubscribe from this group, send email to
> php-standard...@googlegroups.com
> <mailto:php-standards%2Bunsu...@googlegroups.com>.
> > For more options, visit this group at
> http://groups.google.com/group/php-standards?hl=en.
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "PHP Standards Working Group" group.
> To post to this group, send email to php-st...@googlegroups.com
> <mailto:php-st...@googlegroups.com>.
> To unsubscribe from this group, send email to
> php-standard...@googlegroups.com
> <mailto:php-standards%2Bunsu...@googlegroups.com>.
Paul Dragoonis
If we use DateTime it means it lets the implementors decide if it's
TTD or TTL or not. It just depends how you use it that's all.
TTL could be new DateTime('+1 hour'); // (thus 1 hour to live)
TTD could be DateTime::setTimestamp($timestamp); // (thus, $timestamp
is the time to die).
Whatever way you look at it, the DateTime class is flexible and will
not block implementation.
It also advocates proper usage of Date stuff in PHP to push things forward.
Any technical problems with DateTime as the object type for implementors to use?
- Paul.
On Thu, Feb 23, 2012 at 5:05 PM, Larry Garfield <la...@garfieldtech.com> wrote:
> Strictly speaking, if we pass a DateTime then it's a TTD, not a TTL.
>
> That said, I'm fine with going with DateTime since it can emulate
> DateInterval more easily than vice versa. I am wary about allowing
> implementations to extend it with other types, though.
>
> Suppose LarryCache implements integer fallback (assumes it's a timestamp),
> and LuisCode uses it, assuming that it can use integers. Then someone wants
> to use LuisCode inside EvertApp, but EvertApp is already using LukasCache,
> which only supports the baseline DateTime. Asplode!
>
> Asplode is not a good thing for interoperability.
>
> --Larry Garfield
>
>
> On 2/23/12 8:00 AM, Luís Otávio wrote:
>>
>> Evert, I understand your point. I just think that standards should be a
>> little strict ;)
>>
>> Paul, I propose that $ttl can be optional (as mentioned before by
>> yourself), so the signature would be:
>>
>> function set($key, $val, DateTime $ttl = null);
>>
>> Luís
>>
>> On Thu, Feb 23, 2012 at 11:52 AM, Paul Dragoonis <drag...@gmail.com
>> <mailto:drag...@gmail.com>> wrote:
>>
>> Evert,
>>
>> Lets put DateTime into the proposal RFC, we can review it later.
>>
>> function set($key, $val, DateTime $ttl);
>>
>> - Paul
>>
>> On Thu, Feb 23, 2012 at 1:50 PM, Evert Pot <ever...@gmail.com
>> <mailto:ever...@gmail.com>> wrote:
Jordi Boggiano
> If we use DateTime it means it lets the implementors decide if it's
> TTD or TTL or not. It just depends how you use it that's all.
>
> TTL could be new DateTime('+1 hour'); // (thus 1 hour to live)
> TTD could be DateTime::setTimestamp($timestamp); // (thus, $timestamp
> is the time to die).
>
> Whatever way you look at it, the DateTime class is flexible and will
> not block implementation.
> It also advocates proper usage of Date stuff in PHP to push things forward.
>
> Any technical problems with DateTime as the object type for implementors to use?
With TTD, if you implement for redis for example you'll want to call
SETEX foo 10 bar to cache that for 10 seconds, you'd have to take the
DateTime you got as input, diff it with the current time, and by then
maybe it's only 9 seconds left, so you send 9 to redis. This is annoying
logic and can be introduce small errors.
TTL is always clearer IMO, and in most cases if something requires a TTD
you'll anyway produce it using the current time + a TTL in your code, so
why not just stick to the $ttl in seconds arg? It's simple, and it
works. Let it be a float if you need microseconds.
Evert Pot
While I'm not against just using DateTime, I would argue that the 'proper usage' of specifying a TTL is not abusing DateTime for this, but using DateInterval.
Evert
Sebastian Krebs
Just something, that comes in my mind: Besides DateTime/DateInteval is
cool and such, shouldn't a cache be as fast as possible? With this in my
I would suggest to use native integers (as seconds [1]) only. Maybe it's
negligible, but I can imagine, that a site, that makes massive use of
caching, may feel a difference.
Sebastian
[1] The cache can provide several constants for common intervals like
1min, 5min, 15min, 1h, ...
Victor Berchet
I think this is neglectable: you usually cache things that are orders or magnitude slower than the cache (I/O, DB, ...)
So that you don't really care about such small overhead.
(But still I would prefer to have the ability to pass ttl / ttd as integer = no type hint).
Paul Dragoonis
date time, which is fair enough.
I guess the implementors of the cache driver can use DateTime on top
of this interface if they wish.
Lets just keep it at $ttl and not type hint it, then it can be whatever.
Flexibility ++
function set($key, $val, $ttl = null)
Lets keep it at NULL for the $ttl default value, if we done $ttl = 0,
then we'd be hinting that it's a scalar or integer.
- Paul.
Larry Garfield
counter-example to prove it wrong. :-) I am still a bit wary about an
integer, because of how easy it is to inadvertently confuse TTL and TTD
that way.
In this case, leaving $ttl undefined is, I think, a mistake. If
different implementations use different values for it, then they are no
longer interchangeable and the value of a common interface breaks down.
The interface doesn't just include method names, but parameter
expectations and behavior.
This is an area where, I think, a CacheEntry object will help with both
clarity and flexibility. I will try and work up a more fleshed out
proposal for that this weekend as a PR.
--Larry Garfield
Victor Berchet
Paul Dragoonis
down and come back in to push things for proposal.
- Paul.