Changed model-id concept

[Felix Mayerhuber]

Hi,

I've merged now a pull request into the master of the
openengsb-freamework project with which the model ids look different
than they looked before. Until now, every models id was structured in
{domainId}/{connectorId}/{modelId}. This was fine until it was realized
that it is easily possible that the same model could be used by any
connector of the same domain. Also this id concept gave me some headache
because at some points in time I needed additional information which are
not important for the user, but needed to be inserted because it didn't
work otherwise.

From now on, the ids of a model now look like this:
{contextId}/{modelId}. This has the big benefit, that the context id is
always known at any point of execution so the user don't need to pass
this information with its arguments (e.g. in the engineering objects).
But one thing that is important now is, that there may never two models
in the same context which have the same id.

For now I've fixed in the engineering object foreign key definitions,
that they only need to set the model id and not {contextId}/{modelId} in
the id field. But there are some other points (e.g. QueryInterface)
where this change could be interesting.

But to summarize the whole posting: Please be aware if you work with the
current master, that the model id concept changed from
{domainId}/{connectorId}/{modelId} to {contextId}/{modelId}.

Kind regards
Felix

[Michael Petritsch]

Hi,

Where can I set the contextId?

I am currently updating our project from fork-openengsb-framework-19 to 22+.

In 19 DomainId and connectorId were set via the class EKBCommit. However, this class doesn't have a contextId.

br

[Felix Mayerhuber]

Hi,

the contextId is the id of your currently running project. AFAIK an id is set as soon as the OpenEngSB instance is running. However, if you want to set it manually:
 
ContextHolder.get().setCurrentContextId([your context id of choice]);

An example how it is used can be seen here:
https://github.com/openengsb/openengsb-framework/blob/master/components/ekb/persistence-persist-edb/src/test/java/org/openengsb/core/ekb/persistence/persist/edb/PersistInterfaceServiceTest.java

Kind regards,
Felix

--
You received this message because you are subscribed to the Google Groups "OpenEngSB user group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openengsb-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Michael Petritsch]

Hi,

I did set this now, however when inserting transformed signals into 2 different domains, I am still getting the same error as when setting no contextId at all (just contextId 'bar' instead of default 'foo'):

Caused by: org.openengsb.core.edb.api.EDBCheckException: Object with the oid bar/d07f4a6e-0681-4013-acae-5b4e190ac554 exists already. Object with the oid bar/1106a31d-06a0-4ec1-a19c-6f3aaeb7614c exists already. Object with the oid bar/ab0fd0d4-c8bb-4b13-8853-d8a5c61a7899 exists already. Object with the oid bar/e3d9b007-bf87-416c-ba37-508b993fe7dd exists already.

What I am doing:
Insert A models into domain A, transform A models to B models, insert B models into domain B. The exception occurs when inserting signals into domain B.

It seems that with the removal of the domainId from the oid it doesn't work anymore. Or do I have to set anything else besides the contextId?

br

[Michael Petritsch]

>> But one thing that is important now is, that there may never two models in the same context which have the same id.

So when transforming models with the TransformationEngine I have to set new id's now for every B manually instead of using the same as in A?

I don't really know what to think of that change, because when I want to update models (and I always have to update them in at least 2 domains simultaneously) I will have to add a 2nd id that links transformed models across domains. And for every signal I want to update I will have to perform a query on its 'domaintwins'. Or does the edb somehow keep track of transformed signals itself?

Up to now transformed signals in different domains shared the same ModelId which made it easier linking them together.

br

[Felix Mayerhuber]

Hi,

the problem lies a little bit deeper in the functionalities of the EKB. The new model concept helped in a few points inside the EKB were the domain and the connector id needed to be "guessed" because the knowledge about this information was not present. An easy way for you to "link" the models like before, is introducing a prefix in the id? That would solve this problem. However, it seems that you do not set model ids' at all if I see that correctly (the id's in the error message are auto generated), which does not allow the conflict detection that you requested in another thread by the way.

I don't get the question "Or does the edb somehow keep track of transformed signals itself?". What do you mean with that? The EDB saves every model you tell it to save, nothing more and nothing less : )

Kind regards,
Felix

[Michael Petritsch]

Hi,

of course I am setting the ids. 'bar' is just a replacement for the original contextId we are using since this is a public mailinglist. the modelId is a generated UUID. I thought 'bar' would be a good replacement here, since the EngSB uses 'foo' by default.

Ok thanks yes, I can add a prefix for the domain to the modelId as a workaround then. The thing is, from my pov the ekb should do that by itself as it did up to now. Now I have to do a lot more work on my part for the same (most likely worse performing) result and it's also strange that I have to set the domainId twice now (1x with the EKBCommit and 1x for each model). The stored information in the edb is also redundant:

oid=bar/domainA-e3d9b007-bf87-416c-ba37-508b993fe7dd

domainId=domainA

modelField1=...

modelField2=...

and the transformed counterpart:

oid=bar/domainB-e3d9b007-bf87-416c-ba37-508b993fe7dd

domainId=domainB

modelField1=...
modelField2=...

Now I don't have a problem with the connectorId being removed from the oid (never used that), but maybe it would be a better compromise if the ekb would store oids in the following format: {contextId}/{domainId}/{modelId}

br

[Felix Mayerhuber]

Hi,

I was talking about the model ids. Sry, didn't know that you are using UUIDs for that (because this is also what the EKB uses if no id was set by the user).

It is a little bit difficult and also a philosophical discussion about that : ) When I introduced this change, everyone I was talking about it said, that two different models will have two different identifiers. Additionally, Christoph Gritschenberger said that it is a good idea to change the identifier concept in this way, since most of the time the domainId and the connectorId are null anyway.

However, the problem with your suggested concept now is, that there are features in the EKB now, which then have to "guess" the correct domain id for models. I don't know how the future of these features and/or the model concept will look like. Please use this workaround for now.

Personally I have to say I don't know how the EKB should do that by itself, since it can not just generate a name for a model, at least not in a way that it stays recognizable by the user. The stored information is only redundant now because of this workaround. Maybe we can soon find a better solution than that.

Kind regards,
Felix