Re: two values in runtime-substitution Filter vs. processing native_filter

--===============1916386133492087609==
Content-Type: multipart/alternative; boundary="000000000000d6728705964e34fe"

--000000000000d6728705964e34fe
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

So you're seeing a different substitution result when using %key% in:

  FILTER '...%key%...'

versus:

  PROCESSING 'NATIVE_FILTER=3D...%key%'

If so that would be a bug. The value that replaces %key% should be
consistent. The value you supply could be different though because how the
expression is being further processed (e.g. MapServer vs. layer-specific
driver) is different. I'll have to whip up a quick test case to verify.

Otherwise I think in general you'd want to avoid lists if possible and send
things individually so key1=3Dvalue1&key2=3Dvalue2... and then use somethin=
g
like:

    PROCESSING 'NATIVE_FILTER=3D...column in ('%key1%','%key2'%)

I would think validation would be easier in this case but I understand it
might not be practical with an indeterminate number of options. In that
case its probably best to send a completely encoded set of values (complete
with quotes) depending on the diver, so...

  key=3D%27value1%27%2C%27value2%27%2C%27value3%27

and then use:

  PROCESSING 'NATIVE_FILTER=3D...column in ('%key%)

I can't think of an alternative short of 1) adding the ability to split and
format strings before substitution (set a delimiter and a printf pattern)
or 2) adding a function like Perl's qw (quote word) that would handle
string delimiters for you qw(value1,value2). The latter would only work for
FILTERs,

--Steve

On Thu, Oct 31, 2019 at 3:31 AM J=C3=B6rg Thomsen (WhereGroup) <
[email protected]> wrote:

> Good morning everyone,
>
> we built an application which uses a runtime substitution for the filter
> string. And we found a different behavior between (the old) Filter and
> the native_processing filter if two values are parsed.
>
> the request http://....?..&key=3Dvaule1,value2
> results to
> 'value1','value2' with the old FILTER () and to
> 'value1,value2'when using PROCESSING 'NATIVE_FILTER
>
> We have to use the PROCESSING 'NATIVE_FILTER, but need as result
> 'value1','value2', because we want to use it in a sql-query like:
> value in ('value1','value2').
>
> First question:
> has anyone an idea how to handle this? We could request
> http://....?..&key=3Dvalue1','value2
> but that's no nice solution.
>
> Second question: is it the wanted behavior or perhaps a bug?
>
> J=C3=B6rg
>
> --
>
> ***************************
> Where2B Konferenz 2019
> 12. Dezember 2019 in Bonn
> where2b-conference.com
> ***************************
>
> J=C3=B6rg Thomsen
> WhereGroup GmbH
> Gillweg 3
> 14193 Berlin
> Germany
>
> Fon: +49 (0)30 / 5130 278 74
> Fax: +49 (0)30 / 5130 278 11
>
> [email protected]
> www.wheregroup.com
>
> Gesch=C3=A4ftsf=C3=BChrer:
> Olaf Knopp, Peter Stamm
> Amtsgericht Bonn, HRB 9885
>
> -------------------------------
> Folgen Sie der WhereGroup auf twitter: http://twitter.com/WhereGroup_com
> _______________________________________________
> mapserver-users mailing list
> [email protected]
> https://lists.osgeo.org/mailman/listinfo/mapserver-users

--000000000000d6728705964e34fe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">So you&#39;re seeing a different substitution result when =
using %key% in:<div><br></div><div>=C2=A0 FILTER &#39;...%key%...&#39;=C2=
=A0</div><div><br></div><div>versus:</div><div><br></div><div>=C2=A0 PROCES=
SING &#39;NATIVE_FILTER=3D...%key%&#39;</div><div><br></div><div>If so that=
 would be a bug. The value that replaces %key% should be consistent. The va=
lue you supply could be different though because how the expression is bein=
g further processed (e.g. MapServer vs. layer-specific driver) is different=
. I&#39;ll have to whip up a quick test case to verify.</div><div><br></div=
><div>Otherwise I think in general you&#39;d want to avoid lists if possibl=
e and send things individually so key1=3Dvalue1&amp;key2=3Dvalue2... and th=
en use something like:</div><div><br></div><div>=C2=A0 =C2=A0

PROCESSING &#39;NATIVE_FILTER=3D...column in (&#39;%key1%&#39;,&#39;%key2&#=
39;%)</div><div><br></div><div>I would think validation would be easier in =
this case but I understand=C2=A0it might not be practical with an indetermi=
nate number of options. In that case its probably=C2=A0best to send a compl=
etely encoded set of values (complete with quotes) depending on the diver, =
so...</div><div><br></div><div>=C2=A0 key=3D%27value1%27%2C%27value2%27%2C%=
27value3%27</div><div><br></div><div>and then use:</div><div><br></div><div=
>=C2=A0 PROCESSING &#39;NATIVE_FILTER=3D...column in (&#39;%key%)

</div><div><br></div><div>I can&#39;t think of an alternative short of 1) a=
dding the ability to split and format strings before substitution (set a de=
limiter and a printf pattern) or 2) adding a function like Perl&#39;s qw (q=
uote word) that would handle string delimiters for you qw(value1,value2). T=
he latter would only work for FILTERs,</div><div><br></div><div>--Steve</di=
v></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr=
">On Thu, Oct 31, 2019 at 3:31 AM J=C3=B6rg Thomsen (WhereGroup) &lt;<a hre=
f=3D"mailto:[email protected]">[email protected]</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good =
morning everyone,<br>
<br>
we built an application which uses a runtime substitution for the filter<br=
>
string. And we found a different behavior between (the old) Filter and<br>
the native_processing filter if two values are parsed.<br>
<br>
the request http://....?..&amp;key=3Dvaule1,value2<br>
results to<br>
&#39;value1&#39;,&#39;value2&#39; with the old FILTER () and to<br>
&#39;value1,value2&#39;when using PROCESSING &#39;NATIVE_FILTER<br>
<br>
We have to use the PROCESSING &#39;NATIVE_FILTER, but need as result<br>
&#39;value1&#39;,&#39;value2&#39;, because we want to use it in a sql-query=
 like:<br>
value in (&#39;value1&#39;,&#39;value2&#39;).<br>
<br>
First question:<br>
has anyone an idea how to handle this? We could request<br>
http://....?..&amp;key=3Dvalue1&#39;,&#39;value2<br>
but that&#39;s no nice solution.<br>
<br>
Second question: is it the wanted behavior or perhaps a bug?<br>
<br>
J=C3=B6rg<br>
<br>
-- <br>
<br>
***************************<br>
Where2B Konferenz 2019<br>
12. Dezember 2019 in Bonn<br>
<a href=3D"http://where2b-conference.com" rel=3D"noreferrer" target=3D"_bla=
nk">where2b-conference.com</a><br>
***************************<br>
<br>
J=C3=B6rg Thomsen<br>
WhereGroup GmbH<br>
Gillweg 3<br>
14193 Berlin<br>
Germany<br>
<br>
Fon: +49 (0)30 / 5130 278 74<br>
Fax: +49 (0)30 / 5130 278 11=C2=A0 =C2=A0 <br>
<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">joerg.tho=
[email protected]</a><br>
<a href=3D"http://www.wheregroup.com" rel=3D"noreferrer" target=3D"_blank">=
www.wheregroup.com</a><br>
<br>
Gesch=C3=A4ftsf=C3=BChrer:<br>
Olaf Knopp, Peter Stamm<br>
Amtsgericht Bonn, HRB 9885<br>
<br>
-------------------------------<br>
Folgen Sie der WhereGroup auf twitter: <a href=3D"http://twitter.com/WhereG=
roup_com" rel=3D"noreferrer" target=3D"_blank">http://twitter.com/WhereGrou=
p_com</a><br>
_______________________________________________<br>
mapserver-users mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">mapser=
[email protected]</a><br>
<a href=3D"https://lists.osgeo.org/mailman/listinfo/mapserver-users" rel=3D=
"noreferrer" target=3D"_blank">https://lists.osgeo.org/mailman/listinfo/map=
server-users</a></blockquote></div>

--000000000000d6728705964e34fe--

--===============1916386133492087609==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWFwc2VydmVy
LXVzZXJzIG1haWxpbmcgbGlzdAptYXBzZXJ2ZXItdXNlcnNAbGlzdHMub3NnZW8ub3JnCmh0dHBz
Oi8vbGlzdHMub3NnZW8ub3JnL21haWxtYW4vbGlzdGluZm8vbWFwc2VydmVyLXVzZXJz

--===============1916386133492087609==--