URI format used in CCommands when "patching" a model

[agonzalezgaliana]

Hi!

I'm currently trying to test how to do modifications in my model using the model server API. So far I've been able to test this feature with the model server example from here using the client API.

My problem comes when I cannot do small changes in my model (i.e. change the value of an attribute). Commands are successfully executed but after calling "save" the changes are not persisted in the corresponding file (even though the file modification date is updated).

I'm pretty sure that the problem comes from the URI specified in the command, more precisely the owner.$ref.
What's the expected URI format for that attribute? is it a kind of XPath notation?

From the example I can only understand that these references are "cross-document reference" however I could not find more info about it.

Some info would be really appreciated.

Thanks!

[ndoschek]

Hi @agonzalezgaliana!

I suggest to do a simple test run with a REST client to get familiar with the behavior of the Model Server.

This procedure will cover your described way of testing (using the SuperBrewer3000.coffee model from the default workspace root):

1. Set a value of an attribute
   We send a PATCH request containing the following SET command to http://localhost:8081/api/v1/edit?modeluri=SuperBrewer3000.coffee:

{
 "data": {
        "eClass": "http://www.eclipse.org/emfcloud/modelserver/command#//Command",
        "type": "set",
        "owner": {
            "eClass":"http://www.eclipsesource.com/modelserver/example/coffeemodel#//Workflow",
            "$ref":"SuperBrewer3000.coffee#//@workflows.0"
        },
        "feature": "name",
        "dataValues": [ "Auto Brew Workflow" ],
        "indices": [ -1 ]
    }
}

2. Double-check if value has changed
   Then we can double-check if the name of the first workflow element was modified via a GET request to retrieve the model to http://localhost:8081/api/v1/models?modeluri=SuperBrewer3000.coffee.

3. Send save request
   A GET request to http://localhost:8081/api/v1/save?modeluri=SuperBrewer3000.coffee will then persist the file changes.

4. Check if changes are persisted in the file.

Regarding the owner.$ref structure:
The format is basically the URI of the element to change (i.e. the owner). It consists of the modelUri and the elementFragment.
In the previous example those parts of the owner.$ref are:

• modelUri: SuperBrewer3000.coffee
• elementFragment: @workflows.0 (i.e. The first workflow element in the model)

To retrieve an URI for an EObject of your model programmatically, you can use the helper method EcoreUtil.getURI(EObject eObject).

I hope that helps a bit in the meantime and please do not hesitate to come back to us if any more questions arise :)

[agonzalezgaliana]

Hi @ndoschek!

Thanks a lot for your answer. The most valuable tip was the method EcoreUtil.getURI(EObject eObject), with it I was able to get the URI of an object (without that method I wouldn't ever guess it).

By the way, I'm not sure if it would be possible to point to a reference where it explains the format of the element fragment (i.e. why "@" symbols, etc). The only reference I could find (and somehow not complete) is in the EMF book (EMF Eclipse Modeling Framework 2nd edition, Chapter 15.2.3. Resource)

[CamilleLetavernier]

Hi @agonzalezgaliana,

By the way, I'm not sure if it would be possible to point to a reference where it explains the format of the element fragment (i.e. why "@" symbols, etc). The only reference I could find (and somehow not complete) is in the EMF book (EMF Eclipse Modeling Framework 2nd edition, Chapter 15.2.3. Resource)

Do you even need that? In most cases, I think URI fragments can be treated as blackbox unique strings. They should correspond to the "id" attribute of the model element in Json (Or EMF URI Fragment in XMI/Java models); although I'm not sure we always include a consistent "id" attribute in Json (If we don't, we should :) )

There is also no guarantee that they will always be positional IDs (like @workflows.0); some models/languages use generated XMI IDs instead, some could use the (unique) name of the element, or UUID, ... It can really be any kind of unique ID. So you shouldn't make any assumption about the ID format (other than its uniqueness).

[agonzalezgaliana]

Hi @CamilleLetavernier thanks for the contribution. My question about the format is because I'm testing the Model Server API via Postman and therefore I need to write the "PATCH" queries to alter my model. In this way I need to know how to write the element fragment inside the "$ref" URI. Since I did not know "the format" (whether it is an XPath format or similar) I tried lots of combinations to reference the object inside my model (non of them worked).

Thanks to @ndoschek 's answer I know that I can get that element fragment programmatically by using the Java API.

However, if I would have to manually build again the URI (not sure if this would be needed, we're on a technology evaluation phase) I would still not be sure if I'm doing it correctly.

[CamilleLetavernier]

In this way I need to know how to write the element fragment inside the "$ref" URI.

For this, you should:

1. Execute a GET model command
2. See which "id": attribute is returned for the model element you want to edit
3. Use this value to create the URI for the PATCH set command.

If you query the model first, then you don't need to guess the IDs, and it will work with any model/any format.

Unfortunately, I just checked it on the Coffee/Workflow example, and as I feared, IDs are not consistently returned at the moment. I was expecting this result:

"children": [
    {
       "eClass": "http://www.eclipsesource.com/modelserver/example/coffeemodel#//BrewingUnit",
       "id": "//@children.0"
    },

But we actually get:

"children": [
    {
       "eClass": "http://www.eclipsesource.com/modelserver/example/coffeemodel#//BrewingUnit"
    },

In that case, you're right: you have to "guess" the ID, which is really inconvenient (and unreliable).