[PRIP] Support “and”, “or”, “not”, “in” operators #1069
Assignees
Labels
Comments
Woljtek
added
enhancement
17 tasks
|
Tested on Werum testing environment: AND |
|
Tested on Werum testing environment: OR |
|
Tested on Werum testing environment: NOT |
|
Tested on Werum testing environment: IN |
|
Test on Operational Environment OK |
|
Test on Operational Environment OK |
|
Test on Operational Environment OK |
|
Test on Operational Environment No return this seems to be NOK Use following filter : Put result in file : Check attributes Name equal to productType So following my understanding we should have at least this product. Note: When i tried to use this command without filter on product type i have only old AUX Auxiliary which have ingested in begin of 2022 (before we deactivate distribution of AUX DATA in PRIP) NOK |
|
Hi @suberti-ads, can you try again with "productType" instead of "producttype"? I think this might be the problem. Wait, I think I saw somewhere "producttype". I will check again, sorry |
|
Okay, we couldn't confirm your observation in our environment and everything seems to be working fine with the same software version that is deployed in your environment. Because of this we focused the investigation on differences within Elasticsearch and noticed that the PRIP is still not in line with what had been asked in the documentation: https://github.com/COPRS/production-common/blob/develop/processing-common/doc/indices.md I am kind of suprised that there are still differences after we had the anomaly recently with the geofootprint that was not setup as asked. It is still not in line however as the analyzer is not setup and now causing the issue you're finding. It was noticed in RS-779 already that the text search like contains, startWith and endsWith are not working as expected without the analyzer as entries are added in lowercase. This does btw also explain @Woljtek observation with the product type needed to be written in lower case when using the UWC. Please add the analyzer to the PRIP index. Luckily the procedure itself shall be easier than the modification the last time. Have a look at this page: https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-update-settings.html#update-settings-analysis The description of the indices are not a recommendation and are required by the software in order to work correctly. Thus we think that the software is working as expected when the index is fixed. |
|
Dear @w-fsi , For test purprose, we activate this option. New production has been started after this update to generate new product in prip. I took one of last product IW ingested in prip. Put result in file : Check attributes Name equal to productType So we should have at least one product to be returned by "EQ IN" request. |
|
As discussed i tried to the same request using productType in lower case. Its working with this : |
|
Hi @suberti-ads , |
|
Dear @w-fsi , So all tests are OK |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
User story description: "As a end user, I would like to use “and”, “or”, “not”, “in” operators on PRIP/DDIP filter queries so that I can combine different filter functions."
Definition of ready:
Acceptance criteria:
https://$DDIP_URL/odata/v1/Products?$filter=startswith(Name,'S1') and endswith(Name,'.EOF.zip'))https://$DDIP_URL/odata/v1/Products?$filter=contains(Name,'S1_RAW__0S') or contains(Name,'S2_RAW__0S'))https://$DDIP_URL/odata/v1/Products?$filter=startswith(Name,'S1') and not contains(Name,'WV_SLC__1'))https://$DDIP_URL/odata/v1/Products?$filter=Attributes/OData.CSC.StringAttribute/any(att:att/Name eq 'productType' and att/OData.CSC.StringAttribute/Value in ('AUX_WAV','AUX_ICE','AUX_WND')))Note : Tests can be done directly on OPS plateform (see #1071 / #1072)
Definition of Done:
The text was updated successfully, but these errors were encountered: