]> git.saurik.com Git - redis.git/blame_incremental - doc/ReplyTypes.html
store the hash iterator on the heap instead of the stack
[redis.git] / doc / ReplyTypes.html
... / ...
CommitLineData
1
2<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
3<html>
4 <head>
5 <link type="text/css" rel="stylesheet" href="style.css" />
6 </head>
7 <body>
8 <div id="page">
9
10 <div id='header'>
11 <a href="index.html">
12 <img style="border:none" alt="Redis Documentation" src="redis.png">
13 </a>
14 </div>
15
16 <div id="pagecontent">
17 <div class="index">
18<!-- This is a (PRE) block. Make sure it's left aligned or your toc title will be off. -->
19<b>ReplyTypes: Contents</b><br>&nbsp;&nbsp;<a href="#Redis Reply Types">Redis Reply Types</a><br>&nbsp;&nbsp;<a href="#Status code reply">Status code reply</a><br>&nbsp;&nbsp;<a href="#Error reply">Error reply</a><br>&nbsp;&nbsp;<a href="#Integer reply">Integer reply</a><br>&nbsp;&nbsp;<a href="#Bulk reply">Bulk reply</a><br>&nbsp;&nbsp;<a href="#Multi bulk reply">Multi bulk reply</a>
20 </div>
21
22 <h1 class="wikiname">ReplyTypes</h1>
23
24 <div class="summary">
25
26 </div>
27
28 <div class="narrow">
29 <h1><a name="Redis Reply Types">Redis Reply Types</a></h1>Redis commands can reply to the client with four different kind of replies, you can find the protocol level specification of this replies in the <a href="ProtocolSpecification.html">Redis Protocol Specification</a>. This page is instead an higher level description of the four types of replies from the point of view of the final user.<h1><a name="Status code reply">Status code reply</a></h1>
30Status code replies are single line strings having the <b>+</b> character as first byte. The string to return to the client is simply verything that follows the first <b>+</b> character. For example the <a href="PingCommand.html">PING</a> command returns <b>+PONG</b>, that is the string &quot;PONG&quot;.<h1><a name="Error reply">Error reply</a></h1>
31This is like a status code reply but the first character is <b>-</b> instead of <b>+</b>. The client library should raise an error for error replies and stop the execution of the program if the exception is not trapped, showing the error message (everything following the first <b>-</b> character). An example of error is &quot;-Error no such key&quot; or &quot;-foobar&quot;. Note that error replies will not collide with negative integer replies since integer replies are prefixed with the <b>:</b> character.<h1><a name="Integer reply">Integer reply</a></h1>
32At protocol level integer replies are single line replies in form of a decimal singed number prefixed by a <b>:</b> character. For example <b>:10</b> is an integer reply. Redis commands returning <i>true</i> or <i>false</i> will use an integer reply with 0 or 1 as values where 0 is false and 1 is true.<br/><br/>Integer replies are usually passed by client libraries as integer values.<h1><a name="Bulk reply">Bulk reply</a></h1>
33A bulk reply is a binary-safe reply that is used to return a binary safe single string value (string is not limited to alphanumerical strings, it may contain binary data of any kind). Client libraries will usually return a string as return value of Redis commands returning bulk replies. There is a special bulk reply that signal that the element does not exist. When this happens the client library should return 'nil', 'false', or some other special element that can be distinguished by an empty string.<h1><a name="Multi bulk reply">Multi bulk reply</a></h1>
34While a bulk reply returns a single string value, multi bulk replies are used to return multiple values: lists, sets, and so on. Elements of a bulk reply can be missing. Client libraries should return 'nil' or 'false' in order to make this elements distinguishable from empty strings. Client libraries should return multi bulk replies that are about ordered elements like list ranges as lists, and bulk replies about sets as hashes or Sets if the implementation language has a Set type.
35
36 </div>
37
38 </div>
39 </div>
40 </body>
41</html>
42