EDB/EKB related questions

[thrau]

Hi, i have some questions regarding the edb conversion, especially the handling of submodels (i.e. compositions).

## Submodels when loading older revision

As far as i understood the relevant code, when loading an older revision of a model with submodels, the newest submodels are always loaded rather than the versions corresponding to the parent model. Is this intended behaviour, or am i missing something in the code?

## EDBConverterTest

When testing Model -> EDBObject conversion, Submodels are resolved into a flat list. Why does this not resolve to a hierarchy instead?

And: how do i test this in the other direction? How do i go about adding a Submodel to an EDBObject? Is the submodel supposed to be a SubModel instance, or an already resolved EDBObject of this SubModel instance?

(more to come)

tia,

Thomas

[Felix Mayerhuber]

Hi Thomas,

1. This is not intended behaviour. If the code for this is not there, it
seems to have gotten somehow missing : ( Need to have a look at that,
but don't know when I will have time for that.

2. AFAIK the flat list is resolved hierarchically? For a submodel, only
the id of the model should be written in the EDBObject in the end. That
should work, since there are tests for this behaviour. Maybe the thing
you have seen is the resolving of lists of submodels? Because there the
EDB needs a list of ids.

3. On EDB level, there is for every model which is a property, an id of
the model which shall be loaded there placed. So if you want to test the
creation of an EDBObject to a model, you have to write the id of the
other model under the coresponding property name and make sure that the
EDB service can load this id.

Kind regards
Felix

[Felix Mayerhuber]

Hi again,

had a look at 1. Seems like the logic for that has disappeared, no idea why. However, I can remember how I've done that and it wasn't really smart back then. I have now a much easier idea of accomplishing this behaviour, by just considering the time the given model has committed. I will implement this today and set a pull request.

Kind regards
Felix

[Andreas Pieber]

I'll give it a review ASAP I get the notification :-) Thanks Felix!

Kind regards,

Andreas

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

[thrau]

is there a specific reason why the EKB/EDB does not like boolean types (neither primitive nor wrapped?)

[Felix Mayerhuber]

Hi,

I suppose that here is the same error we had already once: Maybe one of
your getters is called "getBoolean" instead of "isBoolean"? We had
already the problem that booleans weren't working and back then, this
was the error.

Kind regards
Felix

[thrau]

primitive booleans seem to work if i use a "get..." prefixed getter instead of an "is...". however they become a problem once ModelUtils.tryToSetValueThroughField is called, and they are assigned null values (which causes exceptions, but could be fixed with a simple null check)

wrapped booleans do not work, as they do not seem to be converted by OpenEngSBModelEntry.toOpenEngSBModelEntries and are thus not delivered to the EDBConverter

[Felix Mayerhuber]

This error must be new. Also I was quite sure that there are tests for this?

about the primitives: only doing a null checker is not enough from my
point of view. It is not allowed that it happens that primitives are
null in our system. I will have a look when I have some spare time.

Kind regards
Felix

[Felix Mayerhuber]

I checked it now, since I was curious. I'm sorry, I can't reproduce the error. At least not on unit test level in the ekb common in the tests for the Model <-> EDBObject conversion. Does this error happen for you during run-time? How exactly are the model structured?

Kind regards,
Felix

[Felix Mayerhuber]

I've now reimplemented the part for recognizing how the setter is named and now both variants are allowed (isXXX or getXXX). I've opened a pull request for that. As soon as this is merged, you can check if the error is still present.

Kind regards,
Felix

[thrau]

heh, i was just about to hack into that piece of code. thanks a lot!