Skip to content

BUG: replacement ids interfering with external ids

Timm Fitschen requested to merge f-mariadb-48 into dev

Summary

Fixes several issues with the flattening of deeply nested properties, the correct storage of data types and minor issues. Most of these issues have been revealed due to the changes in the back end and probably originate from the major refactoring of the server code in the 0.11.0 release (external/internal ids).

Corresponding back end changes: caosdb-mysqlbackend!21 (merged)

Related: caosdb-mysqlbackend#48 (closed)

Focus

The fix of the original issue happened in the back end. However, the fix revealed another bug which had to be fixed in the back end and the server (concerning the property's data type name and id) and another bug in the server (DatabaseUtils) which failed to implement the flattening/de-flattening of the entity properties correctly. This lead to failing integrations tests because the $ prefix of internal ids was leaked into the server's xml response.

Test Environment

See caosdb-mysqlbackend!21 (merged)

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)
    • 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 Timm Fitschen

Merge request reports