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

Filter references without referenced objects (optionally) #603

Closed
novoj opened this issue Jun 12, 2024 · 1 comment · Fixed by #624
Closed

Filter references without referenced objects (optionally) #603

novoj opened this issue Jun 12, 2024 · 1 comment · Fixed by #624
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@novoj
Copy link
Collaborator

novoj commented Jun 12, 2024

evitaDB supports eventual consistency - i.e. allows to have a reference to a not yet existing entity. This is due to the fact that evitaDB usually maintains a secondary index that is gradually updated according to changes in the primary database. This change propagation can't be done transactionally and there can be situations where entity A that references entity B is created first when B starts to exist in evitaDB and it is considered as all right situation.

But when the client queries the data, it usually doesn't want to consider the references to non-existent entities. Except for the situation when it does updates - then it needs to know about the existence of the reference to avoid sending unnecessary upsert mutations to the server.

evitaDB should support this scenario with a new requirement argument - let's call it io.evitadb.api.query.require.ManagedReferencesBehaviour#EXISTING, which would tell the evitaDB engine to filter out references to managed entities that do not yet exist in evitaDB.

This requirement must also handle situations where the target managed entity exists but doesn't satisfy the constraints. For example, the client reads the entity in a particular locale, and the referenced entity doesn't have that locale and therefore can't be returned.

@novoj novoj added the enhancement New feature or request label Jun 12, 2024
@novoj novoj added this to the Beta milestone Jun 12, 2024
@novoj novoj self-assigned this Jun 12, 2024
@novoj
Copy link
Collaborator Author

novoj commented Jun 24, 2024

We will not propagate this requirement to GraphQL API because it's adept for the directives which needs to be researched in different issue: #474

novoj added a commit that referenced this issue Jun 25, 2024
evitaDB supports eventual consistency - i.e. allows to have a reference to a not yet existing entity. This is due to the fact that evitaDB usually maintains a secondary index that is gradually updated according to changes in the primary database. This change propagation can't be done transactionally and there can be situations where entity A that references entity B is created first when B starts to exist in evitaDB and it is considered as all right situation.

But when the client queries the data, it usually doesn't want to consider the references to non-existent entities. Except for the situation when it does updates - then it needs to know about the existence of the reference to avoid sending unnecessary upsert mutations to the server.

evitaDB should support this scenario with a new `requirement` argument - let's call it `io.evitadb.api.query.require.ManagedReferencesBehaviour#EXISTING`, which would tell the evitaDB engine to filter out references to `managed` entities that do not yet exist in evitaDB.

This requirement must also handle situations where the target managed entity exists but doesn't satisfy the constraints. For example, the client reads the entity in a particular locale, and the referenced entity doesn't have that locale and therefore can't be returned.
novoj added a commit that referenced this issue Jun 25, 2024
evitaDB supports eventual consistency - i.e. allows to have a reference to a not yet existing entity. This is due to the fact that evitaDB usually maintains a secondary index that is gradually updated according to changes in the primary database. This change propagation can't be done transactionally and there can be situations where entity A that references entity B is created first when B starts to exist in evitaDB and it is considered as all right situation.

But when the client queries the data, it usually doesn't want to consider the references to non-existent entities. Except for the situation when it does updates - then it needs to know about the existence of the reference to avoid sending unnecessary upsert mutations to the server.

evitaDB should support this scenario with a new `requirement` argument - let's call it `io.evitadb.api.query.require.ManagedReferencesBehaviour#EXISTING`, which would tell the evitaDB engine to filter out references to `managed` entities that do not yet exist in evitaDB.

This requirement must also handle situations where the target managed entity exists but doesn't satisfy the constraints. For example, the client reads the entity in a particular locale, and the referenced entity doesn't have that locale and therefore can't be returned.
lukashornych added a commit that referenced this issue Jun 26, 2024
…referenced-objects-optionally

fix(#603): Filter references without referenced objects (optionally)
novoj added a commit that referenced this issue Jun 26, 2024
novoj added a commit that referenced this issue Jun 28, 2024
novoj added a commit that referenced this issue Jun 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant