You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We want to have both a simple (#127) and a complex (#39) query API. How to delineate them?
The simple bulk API should not need knowledge of the metamodel, i.e. languages, for both repository and client implementations.
We can traverse the model tree/forest in the simple API.
Assume we wanted to "find all instances of MetaPointer x" (with x describing a classifier). Then we have to know the metamodel, as we also want to find instances of sub-x with sub-x extends x.
The text was updated successfully, but these errors were encountered:
I think that for the bulk API the repository should not have to know the languages, but it could (optional).
We can use the same API with a toggle to indicate that the repository should or should not use language information.
This raises a question: a store() call can be refused if the chunk is invalid. A chunk might be valid when the language is not known and be invalid when the language is known. Assuming that a repository knows te he languages involved, who decides that the chunk to be stored is validated against the languages or not, the client or the repository?.
If the client decides this, we might have multiple clients using the repo with and without validation against the languages. This can result in clients that use the repository with language validation to receive (language)incorrect chunks, which is probably unexpected.
We want to have both a simple (#127) and a complex (#39) query API. How to delineate them?
The simple bulk API should not need knowledge of the metamodel, i.e. languages, for both repository and client implementations.
We can traverse the model tree/forest in the simple API.
Assume we wanted to "find all instances of MetaPointer x" (with
x
describing a classifier). Then we have to know the metamodel, as we also want to find instances ofsub-x
withsub-x extends x
.The text was updated successfully, but these errors were encountered: