Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

findEntities with multiple conditions does not return entities #490

Open
pmarius22 opened this issue Feb 24, 2021 · 1 comment
Open

findEntities with multiple conditions does not return entities #490

pmarius22 opened this issue Feb 24, 2021 · 1 comment
Labels
functionality-call To discuss and agree during weekly functionality call(s) question Further information is requested

Comments

@pmarius22
Copy link
Contributor

Hello, I am testing the findEntities method with multiple match conditions and have found a behaviour which I don't know if it's correct.
I am searching for GlossaryTerm type and having as search condition the properties "displayName" and "name" with MatchCriteria.ANY. "displayName" is mapped for GlossaryTerm but the "name" property is not mapped.
While going through the code with the debugger I noticed that because the "name" property is not mapped it results in having the filter set to InstanceMapping.SearchFilter.NONE which means that no results are returned even though the "displayName" is mapped and there should be results matching that property. Also the filter for "displayName" is computed to InstanceMapping.SearchFilter.SOME.

Is this the correct behaviour? I would have expected to receive some results back matching the "displayName" property.

This is what the searchProperties look like:

primitivePropertyValue.setPrimitiveDefCategory(PrimitiveDefCategory.OM_PRIMITIVE_TYPE_STRING);
primitivePropertyValue.setPrimitiveValue("test");
primitivePropertyValue.setTypeName(PrimitiveDefCategory.OM_PRIMITIVE_TYPE_STRING.getName());
primitivePropertyValue.setTypeGUID(PrimitiveDefCategory.OM_PRIMITIVE_TYPE_STRING.getGUID());

namePropertyCondition.setProperty("name");
namePropertyCondition.setOperator(PropertyComparisonOperator.LIKE);
namePropertyCondition.setValue(primitivePropertyValue);

displayNamePropertyCondition.setProperty("displayName);
displayNamePropertyCondition.setOperator(PropertyComparisonOperator.LIKE);
displayNamePropertyCondition.setValue(primitivePropertyValue);

searchProperties.setConditions(Arrays.asList(displayNamePropertyCondition, namePropertyCondition));
searchProperties.setMatchCriteria(MatchCriteria.ANY);
@pmarius22 pmarius22 changed the title Find entities with multiple conditions does not return entities FindEntities with multiple conditions does not return entities Feb 24, 2021
@pmarius22 pmarius22 changed the title FindEntities with multiple conditions does not return entities findEntities with multiple conditions does not return entities Feb 24, 2021
@cmgrote
Copy link
Member

cmgrote commented Feb 26, 2021

This is a good question, given that the GlossaryTerm does not have a property called name is it valid to search for it (?)

The interface itself (findEntities()) suggests that a PropertyErrorException should be thrown if the properties specified are not valid for any of the requested types; however, I assume that in your example this is actually a broader query than just for GlossaryTerm (?) some of which have name and some of which have displayName? In my opinion, this would be better addressed by us putting more consistency in the type model in Egeria along the lines of what I'm suggesting in odpi/egeria#4724 (see the 3rd / 4th comment down). Not only would this make the logic of consumers running queries simpler (not needing to worry about different variations of "name" and how it is represented in different types), but also would make queries more efficient (validating the properties up-front has some cost, but even more costly is doing an OR query that this will inevitably generate).

Such consistency would hopefully address most examples (like this one), but of course the question still remains how this should be handled in general by the query interface -- so suggest we leave this open and I dig further, but that we also tie this back to the consistency point 😬

@cmgrote cmgrote added functionality-call To discuss and agree during weekly functionality call(s) question Further information is requested labels Mar 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
functionality-call To discuss and agree during weekly functionality call(s) question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants