[Geoserver-devel] app-schema numberMatched regression

Hello everyone,

I found a bug in app-schema that was recently introduced by https://osgeo-org.atlassian.net/browse/GEOT-7214, a patch by Marco Volpini, but I am a bit confused about the changes and would like to know to what extent they are intentional. Bug logged at: https://osgeo-org.atlassian.net/browse/GEOT-7214

The problem is situated here: https://github.com/geotools/geotools/blob/main/modules/extension/app-schema/app-schema/src/main/java/org/geotools/data/complex/AppSchemaDataAccess.java#L311

It seems that the true block of the if statement does not unroll the filter. But I am not sure if that could ever make sense or if this was somehow intentional. The changes are only tested by an online integration test on the geoserver side (GetFeatureNumberMatchedGMLTest). The only test method that actually goes inside the true block of the if statement is a test without a filter, so this is actually not being tested.

The problem occurs with an id filter rather than a property name filter. In this case the check does return true and since the filter is not unrolled it cannot work. What should actually happen here? Shouldn't I simply remove this if-statement and always unroll the filter?

Kind Regards

Niels

Dear Niels,
thanks for your point. I think that the block can indeed be removed. I don’t remember why I’ve added that but I did some tests and saw that actually the if statement will evaluate always to false on a property name since the namespace support is null in the AttributeExpressionImpl object at that point. Moreover the JoiningJdbcFeatureSource does checks on its own to determine if the filter is over nested attributes or not.

Regards,

Marco Volpini

==
GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.

Marco Volpini

Software Engineer

GeoSolutions Group
phone: +39 0584 962313

fax: +39 0584 1660272

https://www.geosolutionsgroup.com/

http://twitter.com/geosolutions_it


Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

width= Privo di virus.www.avg.com

On Mon, Sep 12, 2022 at 10:19 AM Niels Charlier <niels@anonymised.com.2918…> wrote:

Hello everyone,

I found a bug in app-schema that was recently introduced by
https://osgeo-org.atlassian.net/browse/GEOT-7214, a patch by Marco
Volpini, but I am a bit confused about the changes and would like to
know to what extent they are intentional. Bug logged at:
https://osgeo-org.atlassian.net/browse/GEOT-7214

The problem is situated here:
https://github.com/geotools/geotools/blob/main/modules/extension/app-schema/app-schema/src/main/java/org/geotools/data/complex/AppSchemaDataAccess.java#L311

It seems that the true block of the if statement does not unroll the
filter. But I am not sure if that could ever make sense or if this was
somehow intentional. The changes are only tested by an online
integration test on the geoserver side (GetFeatureNumberMatchedGMLTest).
The only test method that actually goes inside the true block of the if
statement is a test without a filter, so this is actually not being tested.

The problem occurs with an id filter rather than a property name filter.
In this case the check does return true and since the filter is not
unrolled it cannot work. What should actually happen here? Shouldn’t I
simply remove this if-statement and always unroll the filter?

Kind Regards

Niels

Hello Marco,

Thanks for clearing this up. I have made a PR https://github.com/geotools/geotools/pull/4016

Cheers

Niels

···

On 13/09/2022 08:10, Marco Volpini wrote:

Dear Niels,
thanks for your point. I think that the block can indeed be removed. I don’t remember why I’ve added that but I did some tests and saw that actually the if statement will evaluate always to false on a property name since the namespace support is null in the AttributeExpressionImpl object at that point. Moreover the JoiningJdbcFeatureSource does checks on its own to determine if the filter is over nested attributes or not.

Regards,

Marco Volpini

== GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information. == Marco Volpini

Software Engineer GeoSolutions Group phone: +39 0584 962313

fax: +39 0584 1660272

https://www.geosolutionsgroup.com/

http://twitter.com/geosolutions_it


Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

width= Privo di virus.www.avg.com

On Mon, Sep 12, 2022 at 10:19 AM Niels Charlier <niels@anonymised.com> wrote:

Hello everyone,

I found a bug in app-schema that was recently introduced by
https://osgeo-org.atlassian.net/browse/GEOT-7214, a patch by Marco
Volpini, but I am a bit confused about the changes and would like to
know to what extent they are intentional. Bug logged at:
https://osgeo-org.atlassian.net/browse/GEOT-7214

The problem is situated here:
https://github.com/geotools/geotools/blob/main/modules/extension/app-schema/app-schema/src/main/java/org/geotools/data/complex/AppSchemaDataAccess.java#L311

It seems that the true block of the if statement does not unroll the
filter. But I am not sure if that could ever make sense or if this was
somehow intentional. The changes are only tested by an online
integration test on the geoserver side (GetFeatureNumberMatchedGMLTest).
The only test method that actually goes inside the true block of the if
statement is a test without a filter, so this is actually not being tested.

The problem occurs with an id filter rather than a property name filter.
In this case the check does return true and since the filter is not
unrolled it cannot work. What should actually happen here? Shouldn’t I
simply remove this if-statement and always unroll the filter?

Kind Regards

Niels