http://www.couchbase.com/issues This file is an XML representation of an issue en-us 5.2.4 845 26-12-2012 http://www.couchbase.com/issues/browse/PCBC-137 Couchbase PHP client library Given this code: <br/> <br/> &nbsp;$key = &quot;1&quot;; <br/> &nbsp;$result = $cb-&gt;view(&quot;design&quot;, &quot;view&quot;, array(&quot;key&quot;=&gt;$key)); <br/> <br/> The PHP library will serialize this to a REST request as follows: <br/> <br/> GET /bucket/_design/design/_view/view?key=1 <br/> <br/> This will be deserialized by couchbase as the integer value 1, not as the string value &quot;1&quot;. Consequently, any key that is a string of decimal digits cannot be retrieved from a view with the PHP library. <br/> <br/> This workaround can be used: <br/> <br/> $key = &quot;1&quot;; <br/> $result = $cb-&gt;view(&quot;design&quot;, &quot;view&quot;, array(&quot;key&quot;=&gt;&#39;&quot;&#39;.$key.&#39;&quot;&#39;)); <br/> <br/> The library will serialize this to a REST request as follows: <br/> <br/> GET /bucket/_design/design/_view/view?key=&quot;1&quot; <br/> <br/> And couchbase will deserialize this as the string value &quot;1&quot;. <br/> <br/> <br/> <br/> <br/> PCBC-137

view querying needs to be more straightforward; e.g. character strings of decimal digits are serialised over the REST API as integers in view requests

Bug Blocker Resolved Fixed Public Matt Ingenthron Michael Robinson Thu, 25 Oct 2012 07:19:18 -0500 Tue, 11 Dec 2012 19:59:32 -0600 Fri, 23 Nov 2012 20:21:18 -0600 1.1.0-dp5 1.1.0 0 3 Mark: I saw you mention this earlier. Can you provide an assessment on this? This is a more generalized bug or task of making php aware of the view parameters it passes. <br/> <br/> Currently it only serializes the key-value pairs in the array as is. Having php know about where to place quotes would mean making the client aware abotu the variations in the view parameters, or in other words, implementing all of the view logic in the client library. <br/> <br/> For now the user should be aware of this, and if something clearly mandates &quot;quotes&quot; then it should be quoted already when passed to the array. <br/> <br/> While it&#39;s not the most elegant solution the fix to this is by far not surgical, and thus i recommend changing the name of this bug Would logic equivalent to this not solve the problem? <br/> <br/> if (is_string($params[&quot;key&quot;])) { <br/> &nbsp;&nbsp;$paramString += &#39;key=&quot;&#39;.$params[&quot;key&quot;].&#39;&quot;&#39;; <br/> } <br/> else { <br/> &nbsp;&nbsp;$paramString += &#39;key=&#39;.$params[&quot;key&quot;]; <br/> } No, because there are some parameters which do need actual integers. <br/> <br/> Maybe the server can tolerate numeric parameters even fi they are enclosed in quotes, but I am not sure about that. <br/> <br/> See <br/> <br/> <a href="http://www.couchbase.com/docs/couchbase-manual-2.0/couchbase-views-querying-rest-api.html">http://www.couchbase.com/docs/couchbase-manual-2.0/couchbase-views-querying-rest-api.html</a> - and for example, group_level <br/> <br/> Basically, the php client needs more logic to know the appropriate type for each parameter and perform the necessary coercion. i.e. numeric values for keys are not the same as numeric values for pagination Ok, it seems there are two problems at issue: <br/> <br/> Problem 1: As a general case, type coercions across all parameters in the REST query string are not being handled as intelligently as they could be by the PHP library. <br/> <br/> Problem 2: As a special case of problem 1, the PHP library will silently fail to retrieve records from a view if the key happens to be a string of decimal digits. <br/> <br/> Without addressing the technical or architectural challenges of problem 1, it seems that, with respect to problem 2, as a general principle, silently failing to retrieve valid records for which a valid request was submitted is generally recognized as undesirable behavior for a database system. <br/> <br/> This undesirable behavior could be rectified by the following (and as far as I can see, trivial) change to the serialization logic: <br/> <br/> &nbsp;&nbsp;If the parameter is in the set (&quot;key&quot;, &quot;startkey&quot;, &quot;startkey_docid&quot;, &quot;endkey&quot;, &quot;endkey_docid&quot;), <br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;and if the PHP type of the corresponding parameter value is &quot;string&quot;, <br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;then serialize the parameter value in quotation marks in the REST query string, <br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;otherwise serialize the parameter value according to current implementation. <br/> <br/> Yes? <br/> <br/> <br/> <br/> &nbsp;&nbsp;&nbsp;&nbsp; That does seem to make sense to me Michael. That&#39;s roughly what we evolved to on the other clients (Java &amp;&amp; .NET), but there things are a bit different because of the types. Michael: can you take the lead on documenting a reasonable view query API. You have been through this once before, so I think you&#39;d be the best person here. Simply document it here in this issue and then let&#39;s schedule a quick design review. Here is my proposal. <br/> <br/> I&#39;ve been thinking through and working around this while hacking on Basement (<a href="https://github.com/daschl/Basement">https://github.com/daschl/Basement</a>) and also while extending the Java API. You may see similarities because of this (and you&#39;ll hopefully see why and how it makes sense). <br/> <br/> At the lowest level, I think we should provide two ways of passing in queries in there. <br/> <br/> 1) A plain array as it is now. This way users can work around possible bugs and also have the flexibility if they know what they&#39;re doing. We should clearly state though that they are &quot;on their own&quot; when going down this route. <br/> <br/> 2) A CouchbaseViewQuery object (sorry, since we don&#39;t support namespaces in the extension). This works nearly similar to the Java-one, with the main difference that we need to care about working out the appropriate result type on our own (since you can pass in everything as a variable). <br/> <br/> All further discussion (except noted) refers to the new object and how it should behave. <br/> <br/> The construct should either take no params or an array to be initialized with. If it gets an array, it doesn&#39;t set the params directly but calls each setter for the given key to make sure that all rules are properly enforced. <br/> <br/> Here is a simplified example. It assumes that all setter methods have the name as the param (like key() when setting/getting the key). If we want bean-style setters the method names need to be changed of course. <br/> <br/> class CouchbaseViewQuery { <br/> <br/> // holds the params to be exported <br/> private $params = array(); <br/> <br/> // iterate over the given object an call setters. <br/> public function __construct($params = array()) { <br/> foreach($params as $key =&gt; $value) { <br/> if($value !== null) { <br/> $this-&gt;{$key}($value); <br/> } <br/> } <br/> } <br/> <br/> public function reduce($reduce = null) { <br/> // getter/setter functionality in each method makes it condensed. <br/> if($reduce == null) { <br/> return $this-&gt;params[&#39;reduce&#39;]; <br/> } <br/> <br/> // do appropriate type checking for each param depending on whats <br/> // supported. <br/> if($reduce === &#39;true&#39; || $reduce === true) { <br/> $this-&gt;params[&#39;reduce&#39;] = true; <br/> } <br/> <br/> // return object to let chain setters. <br/> return $this; <br/> } <br/> <br/> } <br/> <br/> Depending on how much we want to change the underlying interface, this query object can have either a toArray() or toString() export method that handles either only exporting it to an array, a string or also handle JSON serialization or encoding (don&#39;t know what of this parts is handled by libcouchbase itself). <br/> <br/> Here is a possible usage example: <br/> <br/> $query = new CouchbaseViewQuery(); <br/> $query-&gt;setReduce(true); // equally to $query-&gt;setReduce(&#39;true&#39;); then <br/> $cb-&gt;view(&#39;design&#39;, &#39;view&#39;, $query); <br/> <br/> Also, all checks and conversions can then be handled transparently and securely by their appropriate setter methods. PHP also provides is_string() and so on to further determine what is passed into the variable. <br/> <br/> Also, the export method is then in the position to do semantical checks like throw a warning/exception when reduce is false (or not set) and a group param is passed on. This could also be done in the setter but I&#39;d like to see it done on exporting to reduce the coupling between setters. <br/> <br/> The query handling object could look similar to this: <a href="https://github.com/daschl/Basement/blob/master/README.md#working-with-views">https://github.com/daschl/Basement/blob/master/README.md#working-with-views</a> (of course the method signature for view querying is differently, but the Query object would be nearly the same). <br/> <br/> Let me know what you think guys, <br/> Michael <br/> For design review. Rank 9773 Time In Status