Custom Converters

[Stefan Scheiber]

Hi,

what would you think about creating the possibility to register a factory for a domain that can create instances of the domain model. This factory would come into play in EDBConverter.convertEDBObjectsToModelObjects
the implementation of this method could first look if there is a factory registered for the domain, in this case it converts using the domain factory, otherwise it uses the default converter (i-e- the current implementation).
The advantage of a factory is that one can design models that have immutable fields.

Another aspect is related to the member field marked with @OpenEngSBModelId. These uuid fields should normally be immutable, however one has to provide a setter method. It would be nice if the default implementation would inject this field without a setter method.

Such a model class is currently not working:

class Program {
   @OpenEngSBModelId
   private String uuid;
   private String name;

   private List<Variable> variables;
  
   public Program(String name) {
     this.name = name;
     uuid = generateUuid();
     variables = new ArrayList<>();
   }

   String getName() {
     return name;
   }
   // no setter for name
   List<Variable> getVariables() {
      return Collections.unmodifiableList(variables);
   }
   // no setter for variables
   public void addVariable(Variable var) {
   }

}

Another option would be to convert model objects to EDBObjects by accessing the non-transient fields and not searching for getter respectively setter methods.

Let me know what you think!

regards,
stefan

[Felix Mayerhuber]

Hi Stefan,

my first thoughts about that below : )

Am 2013-12-12 12:33, schrieb Stefan Scheiber:
> what would you think about creating the possibility to register a factory
> for a domain that can create instances of the domain model. This factory
> would come into play in EDBConverter.convertEDBObjectsToModelObjects
> the implementation of this method could first look if there is a factory
> registered for the domain, in this case it converts using the domain
> factory, otherwise it uses the default converter (i-e- the current
> implementation).
> The advantage of a factory is that one can design models that have
> immutable fields.

IMHO a good idea. This would make the work of the converter easier (with
less reflection). But what we need to discuss and consider here is: if
there is a change in the EDB that affects this area, this would mean
that we have to update all domain specific factories. We need to discuss
if this is an issue or if this is not really a problem.

> Another aspect is related to the member field marked with
> @OpenEngSBModelId. These uuid fields should normally be immutable, however
> one has to provide a setter method. It would be nice if the default
> implementation would inject this field without a setter method.

The thing here is, that the model id does not need to be an uuid. An
uuid is only taken, if the user has not set a value for the id field. So
the automatic setting of an id was in the design the special case and
not the normal case : ).

> Another option would be to convert model objects to EDBObjects by accessing
> the non-transient fields and not searching for getter respectively setter
> methods.

Back then, when this was created, it was necessary that the setter were
accessed instead of the fields because of the following circumstance: It
was possible to modify the set values in the setter. For example, if
there is a field with an unsupported type and you make a getter and
setter which return or accept a String which does the conversion between
this unsupported type and the String. But we need to discuss if we need
this in near future.

Kind regards
Felix

[Stefan Scheiber]

I agree with you on point 1 that factories will have a dependency on the EDBObject interface. The question here is, as you mentioned, how stable this interface is.

I don't think I follow you regarding @OpenEngSBModelId.
The problem is not whether the modelID is a UUID or not, but if  it's mutable or not. I still think that naturally the id is immutable, otherwise when I change the id I'm actually changing the object (i.e. I'm referring to some other entity, i.e. I'm not really updating but inserting)
I should have stated this maybe like this. Whatever is annotated with @OpenEngSBModelId shouldn't necessarily have a setter method. I would still argue that in most cases this field would have no setter.

Regarding the 3rd point I partially agree.
The setter method might not be plain, but might do some other things, however i expect that the edb contains the object's state and not a derivation of its state.

kind regards,
stefan

[Felix Mayerhuber]

Hi,

answers below:

Am 2013-12-16 09:11, schrieb Stefan Scheiber:
> I agree with you on point 1 that factories will have a dependency on the
> EDBObject interface. The question here is, as you mentioned, how stable
> this interface is.

I would say it is rather stable, since this interface has not been
changed for a long time now, even though it will change a little bit
soon (concerning the stage information. But if this makes troubles or
not have to be discussed with Svetoslav)

> I don't think I follow you regarding @OpenEngSBModelId.
> The problem is not whether the modelID is a UUID or not, but if it's
> mutable or not. I still think that naturally the id is immutable, otherwise
> when I change the id I'm actually changing the object (i.e. I'm referring
> to some other entity, i.e. I'm not really updating but inserting)
> I should have stated this maybe like this. Whatever is annotated with
> @OpenEngSBModelId shouldn't necessarily have a setter method. I would still
> argue that in most cases this field would have no setter.

It does make no difference if the model id is a UUID or something else.
The point I have is the following: the ID was designed so that the user
himself defines the ID, not the system. So, naturally, the ID needs to
be mutable : ) The fact that the OpenEngSB gives models with no defined
model id a new UUID was introduced, after the request from the
industrial site came, that there are some models where the user is not
interested to set an ID since the model is just a temporary "throw away"
model.

> Regarding the 3rd point I partially agree.
> The setter method might not be plain, but might do some other things,
> however i expect that the edb contains the object's state and not a
> derivation of its state.

The solution has been chosen some time ago where we had the problem that
some objects could not be saved by the EDB natively (since they had no
string equivalent built in). Nowadays we can solve such problems in the
EDBConverter. So, I suppose, it should be no problem to access the
properties directly. We just have to decide on that.

Kind regards
Felix