[Geoserver-devel] Pull request #841 / CQL concatenation

GeoServer GeoServer Developer
1

Hi,

Jody and I have been discussing my pull request on cascaded stored requests and we’d like to open another point to wider debate.

This is regarding Jody’s notes on this test case:
https://github.com/geoserver/geoserver/pull/841#discussion-diff-21495146

Some background: my implementation of cascaded stored query passes stored query parameters to the backend via two mechanisms:

  1. The original request to the feature type backed by a cascaded stored query may include view parameters, just like with Virtual Table backed feature types.

  2. Feature type configuration may specify mappings to the parameters.
    There are a two types of mappings possible in the implementation. You can either specify a default value (two flavours: one you can override with a view parameter and another you can’t), or the parameter value can be evaluated from an expression. The discussion here is regarding these expressions.

The expressions are written in CQL and are executed within a context where the query filter, basic feature type information and the query bounds are accessible. A stored query that my work specifically targets has a bounding box parameter that needs to be derived from this context. I used expressions instead of a hard-coded bounding box type parameter mapping to make the implementation more general.

When I wrote the CQL expression parts, I was only aware of a single concatenation function in CQL, strConCat. This function only takes two parameters and both must be strings. So as you can see in the test referenced by the diff, the expression to build a bounding box becomes quite a mess. To avoid this, I overrode the + operator for these expressions so it does string concatenation if either the left hand side or right hand side values were strings.

https://github.com/geotools/geotools/blob/master/modules/unsupported/wfs-ng/src/main/java/org/geotools/data/wfs/internal/v2_0/storedquery/ParameterCQLExpressionFilterFactoryImpl.java#L104

However, Jody led me on to the fact that there is a multi-parameter concatenation function in CQL.

Now the question is: should I remove the overridden + operator and go with the standard concatenation function?

Also: I was unable to find reference documentation on this concatenation function. Maybe someone knows where it is so I can check it? Especially whether it allows combining numbers and strings is of interest.

Sampo

···

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

2

Thanks for taking discussion to the email list.

For your question: “should I remove the overridden + operator and go with the standard concatenation function?”

We have a similar requirement in a few places in our code (handling of labels in SLD, and handling of embedded CQL expressions in external graphics). In these cases rather than use “+” we use whitespace - resulting in a list of expressions that can be evaluated).

I think ECQL has a method that takes a lis of expressions separated by “;” as well.

Would you be with using white space to produce your Concatenate expression? This would make the codebase a bit more consistent (and one less opportunity for confusion).

···

On 11 December 2014 at 00:44, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

Jody and I have been discussing my pull request on cascaded stored requests and we’d like to open another point to wider debate.

This is regarding Jody’s notes on this test case:
https://github.com/geoserver/geoserver/pull/841#discussion-diff-21495146

Some background: my implementation of cascaded stored query passes stored query parameters to the backend via two mechanisms:

  1. The original request to the feature type backed by a cascaded stored query may include view parameters, just like with Virtual Table backed feature types.

  2. Feature type configuration may specify mappings to the parameters.
    There are a two types of mappings possible in the implementation. You can either specify a default value (two flavours: one you can override with a view parameter and another you can’t), or the parameter value can be evaluated from an expression. The discussion here is regarding these expressions.

The expressions are written in CQL and are executed within a context where the query filter, basic feature type information and the query bounds are accessible. A stored query that my work specifically targets has a bounding box parameter that needs to be derived from this context. I used expressions instead of a hard-coded bounding box type parameter mapping to make the implementation more general.

When I wrote the CQL expression parts, I was only aware of a single concatenation function in CQL, strConCat. This function only takes two parameters and both must be strings. So as you can see in the test referenced by the diff, the expression to build a bounding box becomes quite a mess. To avoid this, I overrode the + operator for these expressions so it does string concatenation if either the left hand side or right hand side values were strings.

https://github.com/geotools/geotools/blob/master/modules/unsupported/wfs-ng/src/main/java/org/geotools/data/wfs/internal/v2_0/storedquery/ParameterCQLExpressionFilterFactoryImpl.java#L104

However, Jody led me on to the fact that there is a multi-parameter concatenation function in CQL.

Now the question is: should I remove the overridden + operator and go with the standard concatenation function?

Also: I was unable to find reference documentation on this concatenation function. Maybe someone knows where it is so I can check it? Especially whether it allows combining numbers and strings is of interest.

Sampo

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Jody Garnett

3

Hi,

Interesting. To clarify, would this mean the expression [ foo + ‘,’ + bar ] in my current branch would be replaced by [ foo ‘,’ bar ] (brackets are there only to separate expressions from text)? And this would mean the value of foo concatenated to ‘,’ concatenated to the valut of bar?

If so, this definitely is a workable solution in my case as well. It’s definitely best if we can avoid having slightly different CQL syntax in different places.

Sampo

···

On Thu, Dec 11, 2014 at 8:19 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Thanks for taking discussion to the email list.

For your question: “should I remove the overridden + operator and go with the standard concatenation function?”

We have a similar requirement in a few places in our code (handling of labels in SLD, and handling of embedded CQL expressions in external graphics). In these cases rather than use “+” we use whitespace - resulting in a list of expressions that can be evaluated).

I think ECQL has a method that takes a lis of expressions separated by “;” as well.

Would you be with using white space to produce your Concatenate expression? This would make the codebase a bit more consistent (and one less opportunity for confusion).

Jody

–

–
Jody Garnett

On 11 December 2014 at 00:44, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

Jody and I have been discussing my pull request on cascaded stored requests and we’d like to open another point to wider debate.

This is regarding Jody’s notes on this test case:
https://github.com/geoserver/geoserver/pull/841#discussion-diff-21495146

Some background: my implementation of cascaded stored query passes stored query parameters to the backend via two mechanisms:

  1. The original request to the feature type backed by a cascaded stored query may include view parameters, just like with Virtual Table backed feature types.

  2. Feature type configuration may specify mappings to the parameters.
    There are a two types of mappings possible in the implementation. You can either specify a default value (two flavours: one you can override with a view parameter and another you can’t), or the parameter value can be evaluated from an expression. The discussion here is regarding these expressions.

The expressions are written in CQL and are executed within a context where the query filter, basic feature type information and the query bounds are accessible. A stored query that my work specifically targets has a bounding box parameter that needs to be derived from this context. I used expressions instead of a hard-coded bounding box type parameter mapping to make the implementation more general.

When I wrote the CQL expression parts, I was only aware of a single concatenation function in CQL, strConCat. This function only takes two parameters and both must be strings. So as you can see in the test referenced by the diff, the expression to build a bounding box becomes quite a mess. To avoid this, I overrode the + operator for these expressions so it does string concatenation if either the left hand side or right hand side values were strings.

https://github.com/geotools/geotools/blob/master/modules/unsupported/wfs-ng/src/main/java/org/geotools/data/wfs/internal/v2_0/storedquery/ParameterCQLExpressionFilterFactoryImpl.java#L104

However, Jody led me on to the fact that there is a multi-parameter concatenation function in CQL.

Now the question is: should I remove the overridden + operator and go with the standard concatenation function?

Also: I was unable to find reference documentation on this concatenation function. Maybe someone knows where it is so I can check it? Especially whether it allows combining numbers and strings is of interest.

Sampo

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com9…
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.