Looking good Martin.  No objections from me.  The old QgsSearchString was a bit string in the way it handled a few things so I&#39;m glad it&#39;s been simplified in your chances.  <div><br></div><div>I&#39;m just merging with my expression labeling branch, which used QgsSearchString at the moment. I will report if I find any bugs.</div>

<div><br></div><div>- Nathan<br><br><div class="gmail_quote">On Sat, Aug 20, 2011 at 6:51 AM, Martin Dobias <span dir="ltr">&lt;<a href="mailto:wonder.sk@gmail.com">wonder.sk@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Hi everyone<br>
<br>
recently I have been trying to fix some flaws in search string<br>
implementation and it turned out that rather than fixing them<br>
one-by-one it will be easier to rewrite that code completely. Search<br>
string and associated searching in attribute table was one of my first<br>
contributions to QGIS and my first attempt to write a parser and an<br>
evaluator. QgsExpression is my second attempt :-)<br>
<br>
The main reason for the redesign was to bring the evaluation closer to<br>
SQL semantics and to clean the code which started to be hard to<br>
maintain.<br>
<br>
QgsExpression is meant to be a replacement for QgsSearchString class.<br>
Most of the changes are under the hood:<br>
- fixed and simplifed the parser grammar and tree creation<br>
- simplified lexer<br>
- only one evaluation routine (instead of separate getValue/checkAgainst)<br>
- correct handling of NULL values and three-value logic from SQL<br>
(true, false, unknown)<br>
- fixed error reporting<br>
- easily extensible list of functions, saner evaluation of expressions<br>
- using QVariant for return values instead of a special type<br>
- slightly faster evaluation<br>
- a more suitable class name<br>
- tests included (!!!) :-)<br>
<br>
Only few changes are visible for users:<br>
- spaces were removed from &quot;to int&quot;, &quot;to real&quot; and &quot;to string&quot;<br>
functions because function names must not contain spaces<br>
- null values are handled correctly by the functions and operators<br>
- errors are reported when conversions between types fail<br>
<br>
Btw. type conversions (currently supporting null, int, double, string)<br>
are implemented in many different ways in databases. I have done some<br>
tests on sqlite3, postgresql and mysql and many times there was no<br>
consensus what the outcome of an evaluation should be:<br>
- 7 &gt; &#39;6x&#39; :: mysql=1, sqlite=0, postgresql=error<br>
- 7 &gt; &#39;6&#39; :: mysql=1, sqlite=0 (!), postgresql=1<br>
- &#39;6x&#39; :: mysql=6 (+warning), sqlite=6, postgresql=error<br>
- &#39;3&#39;+&#39;5&#39; :: mysql=8, sqlite=8, postgresql=error<br>
- 3/5 :: mysql=0.6, sqlite=0, postgresql=0<br>
- length(123) :: mysql=3, sqlite=3, postgresql=error<br>
- 0 or 1 :: mysql=1, sqlite=1, postgresql=error<br>
- 0 or &#39;x&#39; :: mysql=0 (+warning), sqlite=0, postgresql=error<br>
<br>
PostgreSQL is very strict about type conversions, Sqlite is not strict<br>
at all and MySQL is somewhere in the middle. I have ended up with<br>
these conversion rules:<br>
- implicit conversions to desired types<br>
- string-&gt;number conversions with invalid input return error<br>
- arithmetic operators convert to numeric<br>
- comparison with numeric type =&gt; numeric comparison<br>
<br>
<br>
The code is here:<br>
<a href="https://github.com/wonder-sk/Quantum-GIS/tree/expr" target="_blank">https://github.com/wonder-sk/Quantum-GIS/tree/expr</a><br>
<br>
If there are no objections I will apply the changes to master in few<br>
days. Given that I have been simultaneously writing unit tests I am<br>
quite confident that there are not too many bugs (unit tests really<br>
help!). In that branch I have replaced all the occurrences of search<br>
string with expressions. So playing with search in attribute table or<br>
doing calculation in field calculator will use the new engine.<br>
<br>
<br>
Martin<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div><br></div>