-
Notifications
You must be signed in to change notification settings - Fork 7
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
It's possible to create reference targetting non-existing evitaDB entity type #162
Comments
Unfortunately, this issue was created in a hurry without a proper description of what it really means. Closed for now - if it's a problem, it should come up again. |
@novoj I think it was created when I was writing the "Write data" docs chapter, where it allowed me to create reference to evitaDB-managed |
Thank you! I will fix it today then. |
Former implementation allowed to create reference targeting non-existing evitaDB entity type.
…erence-targetting-non-existing-evitadb-entity-type fix(#162): add validation for managed entity references
This implementation broke a lot of tests and I'm afraid it would break current clients as well. I think we need to postpone validation and allow multiple schemas to be defined in bulk to avoid unnecessary complexity on the client side while maintaining model consistency. Current use case: Product -> References Category It's a circular dependency, but it's a real use case that we need to support. The only situation to avoid the exception would be
This requires quite complicated setup on the client side, which now uses the So a new suggestion would be to validate the schema not in the mutation, but at the end of the updateSchema method. In |
I agree with this solution. I've checked the GraphQL API where the problem occurs and the exception is thrown when the GraphQL API is being regenerated after schema update, so this should play well with your idea. |
Reworked original implementation which broke a lot of tests and I'm afraid it would break current clients as well. I think we need to postpone validation and allow multiple schemas to be defined in bulk to avoid unnecessary complexity on the client side while maintaining model consistency. Current use case: Product -> References Category category -> references products (related products specified at category level) It's a circular dependency, but it's a real use case that we need to support. The only situation to avoid the exception would be 1. create category 2. create product that references category 3. change category to reference related products This requires quite complicated setup on the client side, which now uses the `ClassAnalyzer` facility to set up the schema. So a new suggestion would be to validate the schema not in the mutation, but at the end of the updateSchema method. In `io.evitadb.core.EvitaSession#updateCatalogSchema` method the validation will be done after all mutations have been processed. This would allow to set up circular dependent updates in one go and still pass the validation.
Cleaning - two interfaces joined together.
Few grey hairs later ... it's finally done. |
This should clearly not be possible.
The text was updated successfully, but these errors were encountered: