valkey/doc/ExpireCommand.html


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
    <head>
        <link type="text/css" rel="stylesheet" href="style.css" />
    </head>
    <body>
        <div id="page">
        
            <div id='header'>
            <a href="index.html">
            <img style="border:none" alt="Redis Documentation" src="redis.png">
            </a>
            </div>
        
            <div id="pagecontent">
                <div class="index">
<!-- This is a (PRE) block.  Make sure it's left aligned or your toc title will be off. -->
<b>ExpireCommand: Contents</b><br>&nbsp;&nbsp;<a href="#Expire _key_ _seconds_">Expire _key_ _seconds_</a><br>&nbsp;&nbsp;&nbsp;&nbsp;<a href="#How the expire is removed from a key">How the expire is removed from a key</a><br>&nbsp;&nbsp;&nbsp;&nbsp;<a href="#Restrictions with write operations against volatile keys">Restrictions with write operations against volatile keys</a><br>&nbsp;&nbsp;&nbsp;&nbsp;<a href="#Setting the timeout again on already volatile keys">Setting the timeout again on already volatile keys</a><br>&nbsp;&nbsp;&nbsp;&nbsp;<a href="#Return value">Return value</a><br>&nbsp;&nbsp;&nbsp;&nbsp;<a href="#See also">See also</a>
                </div>
                
                <h1 class="wikiname">ExpireCommand</h1>

                <div class="summary">
                    
                </div>

                <div class="narrow">
                    <h1><a name="Expire _key_ _seconds_">Expire _key_ _seconds_</a></h1>
<i>Time complexity: O(1)</i><blockquote>Set a timeout on the specified key. After the timeout the key will beautomatically delete by the server. A key with an associated timeout issaid to be <i>volatile</i> in Redis terminology.</blockquote>
<blockquote>Voltile keys are stored on disk like the other keys, the timeout is persistenttoo like all the other aspects of the dataset. Saving a dataset containingthe dataset and stopping the server does not stop the flow of time as Redisregisters on disk when the key will no longer be available as Unix time, andnot the remaining seconds.</blockquote>
<h2><a name="How the expire is removed from a key">How the expire is removed from a key</a></h2><blockquote>When the key is set to a new value using the SET command, the INCR commandor any other command that modify the value stored at key the timeout isremoved from the key and the key becomes non volatile.</blockquote>
<h2><a name="Restrictions with write operations against volatile keys">Restrictions with write operations against volatile keys</a></h2><blockquote>Write operations like LPUSH, LSET and every other command that has theeffect of modifying the value stored at a volatile key have a special semantic:basically a volatile key is destroyed when it is target of a write operation.See for example the following usage pattern:</blockquote>
<pre class="codeblock python" name="code">
% ./redis-cli lpush mylist foobar /Users/antirez/hack/redis
OK
% ./redis-cli lpush mylist hello  /Users/antirez/hack/redis
OK
% ./redis-cli expire mylist 10000 /Users/antirez/hack/redis
1
% ./redis-cli lpush mylist newelement
OK
% ./redis-cli lrange mylist 0 -1  /Users/antirez/hack/redis
1. newelement
</pre><blockquote>What happened here is that lpush against the key with a timeout set deletedthe key before to perform the operation. There is so a simple rule, writeoperations against volatile keys will destroy the key before to perform theoperation. Why Redis uses this behavior? In order to retain an importantproperty: a server that receives a given number of commands in the samesequence will end with the same dataset in memory. Without the delete-on-writesemantic what happens is that the state of the server depends on the timeof the commands to. This is not a desirable property in a distributed databasethat supports replication.</blockquote>
<h2><a name="Setting the timeout again on already volatile keys">Setting the timeout again on already volatile keys</a></h2><blockquote>Trying to call EXPIRE against a key that already has an associated timeoutwill not change the timeout of the key, but will just return 0. If insteadthe key does not have a timeout associated the timeout will be set and EXPIREwill return 1.</blockquote>
<h2><a name="Return value">Return value</a></h2><a href="ReplyTypes.html">Integer reply</a>, specifically:<br/><br/><pre class="codeblock python python" name="code">
1: the timeout was set.
0: the timeout was not set since the key already has an associated timeout, or the key does not exist.
</pre><h2><a name="See also">See also</a></h2>
<ul><li> <a href="TypeCommand.html">TYPE</a></li></ul>
                </div>
        
            </div>
        </div>
    </body>
</html>
CPP client added thanks to Brian Hammond 2009-05-09 07:25:59 +00:00
			`<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">`
			`<html>`
			`<head>`
			`<link type="text/css" rel="stylesheet" href="style.css" />`
			`</head>`
			`<body>`
			`<div id="page">`

			`<div id='header'>`
			`<a href="index.html">`
			`<img style="border:none" alt="Redis Documentation" src="redis.png">`
			`</a>`
			`</div>`

			`<div id="pagecontent">`
			`<div class="index">`
			`<!-- This is a (PRE) block. Make sure it's left aligned or your toc title will be off. -->`
			<b>ExpireCommand: Contents</b><br>  <a href="#Expire _key_ _seconds_">Expire _key_ _seconds_</a><br>    <a href="#How the expire is removed from a key">How the expire is removed from a key</a><br>    <a href="#Restrictions with write operations against volatile keys">Restrictions with write operations against volatile keys</a><br>    <a href="#Setting the timeout again on already volatile keys">Setting the timeout again on already volatile keys</a><br>    <a href="#Return value">Return value</a><br>    <a href="#See also">See also</a>
			`</div>`

			`<h1 class="wikiname">ExpireCommand</h1>`

			`<div class="summary">`

			`</div>`

			`<div class="narrow">`
			`<h1><a name="Expire _key_ _seconds_">Expire _key_ _seconds_</a></h1>`
			`<i>Time complexity: O(1)</i><blockquote>Set a timeout on the specified key. After the timeout the key will beautomatically delete by the server. A key with an associated timeout issaid to be <i>volatile</i> in Redis terminology.</blockquote>`
			`<blockquote>Voltile keys are stored on disk like the other keys, the timeout is persistenttoo like all the other aspects of the dataset. Saving a dataset containingthe dataset and stopping the server does not stop the flow of time as Redisregisters on disk when the key will no longer be available as Unix time, andnot the remaining seconds.</blockquote>`
			`<h2><a name="How the expire is removed from a key">How the expire is removed from a key</a></h2><blockquote>When the key is set to a new value using the SET command, the INCR commandor any other command that modify the value stored at key the timeout isremoved from the key and the key becomes non volatile.</blockquote>`
			`<h2><a name="Restrictions with write operations against volatile keys">Restrictions with write operations against volatile keys</a></h2><blockquote>Write operations like LPUSH, LSET and every other command that has theeffect of modifying the value stored at a volatile key have a special semantic:basically a volatile key is destroyed when it is target of a write operation.See for example the following usage pattern:</blockquote>`
			`<pre class="codeblock python" name="code">`
			`% ./redis-cli lpush mylist foobar /Users/antirez/hack/redis`
			`OK`
			`% ./redis-cli lpush mylist hello /Users/antirez/hack/redis`
			`OK`
			`% ./redis-cli expire mylist 10000 /Users/antirez/hack/redis`
			`1`
			`% ./redis-cli lpush mylist newelement`
			`OK`
			`% ./redis-cli lrange mylist 0 -1 /Users/antirez/hack/redis`
			`1. newelement`
			</pre><blockquote>What happened here is that lpush against the key with a timeout set deletedthe key before to perform the operation. There is so a simple rule, writeoperations against volatile keys will destroy the key before to perform theoperation. Why Redis uses this behavior? In order to retain an importantproperty: a server that receives a given number of commands in the samesequence will end with the same dataset in memory. Without the delete-on-writesemantic what happens is that the state of the server depends on the timeof the commands to. This is not a desirable property in a distributed databasethat supports replication.</blockquote>
			`<h2><a name="Setting the timeout again on already volatile keys">Setting the timeout again on already volatile keys</a></h2><blockquote>Trying to call EXPIRE against a key that already has an associated timeoutwill not change the timeout of the key, but will just return 0. If insteadthe key does not have a timeout associated the timeout will be set and EXPIREwill return 1.</blockquote>`
			`<h2><a name="Return value">Return value</a></h2><a href="ReplyTypes.html">Integer reply</a>, specifically:<br/><br/><pre class="codeblock python python" name="code">`
			`1: the timeout was set.`
			`0: the timeout was not set since the key already has an associated timeout, or the key does not exist.`
			`</pre><h2><a name="See also">See also</a></h2>`
doc changes 2009-05-09 07:58:26 +00:00			`<ul><li> <a href="TypeCommand.html">TYPE</a></li></ul>`
CPP client added thanks to Brian Hammond 2009-05-09 07:25:59 +00:00			`</div>`

			`</div>`
			`</div>`
			`</body>`
			`</html>`