ID returned in responses shouldn't be there

[cochicde]

I tried the SR and Ochestrator and they return an ID for service, system and some others maybe. This presents a problem since the ID shouldn't be part of the response according to the arrowhead definition. After some emails about this, I open this issue to discuss this.

The main question are: why is the ID returned in the response? who uses it?

What would break if we get rid of it?

[hegeduscs]

The management tool UI uses it (React JS), should only be present in the mgmt interfaces.

[uzoltan]

Entity classes have IDs (found in the eu.arrowhead.common.database package), so the database handling library can write to and retrieve values from the database. As a unique identifier of a resource, it is also useful keeping track, if case it needs to be updated/deleted/specified.

Besides the id field not being part of the definition, do you have other issues with it?

[cochicde]

The issue I have with the IDs is that when the parser of the response finds it, it detects an error as a wrong type. I think the ID is fine for internal usage, I believe this shouldn't go outside of the core systems.

I have some other issues with the metadata and the orchestrationflags but those problem come from the definition itself not the implementation.

[uzoltan]

Can I ask what kind of parser do you use? Isn't it possible with the parser to ignore unknown fields?

I could "manually" delete the IDs from the objects, before returning an OrchestrationResponse or ServiceRegistryEntry (when it is not from a management API), although I'm not happy about it, if feels like a rudimentary solution to me.

[cochicde]

we're using our own parser. We transform the JSON string into a string according to a standard for automation which states how structures should look like (which is rather easy to transfom). The standard doesn't allow for unkown fields, so that's why when we transform, we "clean" all the IDs. So for now it's working.

But the problem is not if I or other users can adapt to this field, but that even the oficial implementation of the Arrowhead system is not conform to the arrowhead specifications. This could be a simple issue to overcome, but from my point of view interfaces are sacred and shouldn't be broken.

I don't want to change something because it bothers me, but because from my point of view is wrongly implemented. I put the issue here for discussion and to see what other users think about it. I'll be glad to help if a lot of change is needed

[uzoltan]

I'll be glad to help if a lot of change is needed

That depends on the quality of the solution :) But for now I think I'll keep this as an open issue. There are other problems with the database design we know about, so bigger changes are bound to happen anyway, where this can be solved/clarified.
I'm not sure what is Csaba's viewpoint on all of this, specially the

even the oficial implementation of the Arrowhead system is not conform to the arrowhead specifications.

part of it.

[hegeduscs]

I don't agree with having the ID fields in the messages either. That is not documented, nor should be.

The primary key for an Arrowhead system is its name, which should be unique within the LC.

The mgmt interfaces could contain this field, so that the Javascript UI can be implemented easier. Maybe I need to revisit this allowance as well, even if things are harder to implement.

I hope Jose, you are coming to Bilbao to discuss how you could help us in the works.

[cochicde]

I'll be in Bilbao, yes. That'd be a great time to disscuss personally this things