Skip to content

FIX: fix for 203

Henrik tom Wörden requested to merge f-bracket-has into dev

Summary

Fixes https://gitlab.com/caosdb/caosdb-server/-/issues/203

Focus

Allow "has" after brackets. E.g.:

  • FIND ename WHICH ( HAS pname )
  • FIND ename WHICH ( HAS pname and references ename2 )

Notes

This fixes the given bug. However, I would like to raise the question whether the change should go further.

We allow queries like FIND ename WHICH HAS pname WHICH HAS pname2 and since HAS can be interpreted as WHICH HAS we can also write FIND guitar which ( HAS latitude) (Brackets prevent "which has" to be consumed at once. Thus because the expression for the entity can be omitted, it cannot be distinguished, whether this is a "which has" where for some reason brackets where inserted or whether it is a "which has a X which has a Y".

I would suggest to simplify things by not treating "HAS" as "WHICH HAS". When we look in the parser, the which_exp always requires some "which" like part ("which" itself, "with" as "synonyom" for "which has", "where", etc.). Except for "HAS". Introducing this change would make clear that a which_exp means another level, i.e. usually a subproperty. This would also make clear, that all parts of "HAS A PROPERTY" are syntactic sugar and can be omitted. It is not sometimes sugar and sometimes not. (see !87)

Test Environment

unit test

Check List for the Author

Please, prepare your MR for a review. Be sure to write a summary and a focus and create gitlab comments for the reviewer. They should guide the reviewer through the changes, explain your changes and also point out open questions. For further good practices have a look at our review guidelines

  • All automated tests pass
  • Reference related issues
  • Up-to-date CHANGELOG.md (or not necessary)
  • Up-to-date JSON schema (or not necessary)
  • Appropriate user and developer documentation (or not necessary) (see #294 (closed) and !89 (merged))
    • How do I use the software? Assume "stupid" users.
    • How do I develop or debug the software? Assume novice developers.
  • Annotations in code (Gitlab comments)
    • Intent of new code
    • Problems with old code
    • Why this implementation?

Check List for the Reviewer

  • I understand the intent of this MR
  • All automated tests pass
  • Up-to-date CHANGELOG.md (or not necessary)
  • Appropriate user and developer documentation (or not necessary)
  • The test environment setup works and the intended behavior is reproducible in the test environment
  • In-code documentation and comments are up-to-date.
  • Check: Are there specifications? Are they satisfied?

For further good practices have a look at our review guidelines.

Edited by Henrik tom Wörden

Merge request reports