@Preupdate com @Transient - Eclipselink

Asked

Viewed 111 times

2

I need a @Preupdate method to be called when a @Transient attribute is modified. This @Transient will always be modified, so yes, @Preupdate would have to be called every time. Since it will always have to be called, I looked for an option similar to @Preupdate, but that was called regardless of whether it has modified attributes or not, because it is this method that will define the value of a column to be persisted, according to the value in @Transient. The alternative I found was to define the following attributes:

@Column(name="valor")
private Double valor;

@Column(name="valor", insertable=false, updatable=false)
private Double valorTransientDisfarcado;

Thus, the "Transient" will always be loaded with the column value that it will possibly change. Case that "Transient" be changed, it will fall into @Preupdate and perform some operations that will define whether the value it has will be transmitted to the attribute "original" to be persisted.

The question is: What problems can this approach bring?

And is there any alternative to that value "Transient"?
Better yet, there is some alternative to @Preupdate, so that the method is called at the last possible moment, regardless if there are changes, until now, to be persisted, so that it only performs the verification of the modified attributes after this method?

  • How would this attribute be @Transient you couldn’t put this @Preupdate logic into the Setter of that attribute? Thus, when the value of the Transient is changed (through the setTransient()) it can be validated and modify the other attribute valorTransientDisfarcado

1 answer

0

Following good Separation of Concerns (Soc) principles it would not be legal to delegate this rule to your data retention layer. Note that looking only your code snippet already exists a redundancy in the column name, which makes legibildiade difficult.

Prefer to use the Object Orientation (OO) tools since this field is not persisted and use, for example, a Decorator in your class with the appropriate getters/setters.

See the Python zen, principles of good programming practice, which

explicit is better than implicit.

Therefore I strongly recommend that you put your rules on a DAO and write automated test cases. It is a much less tortuous way than observing the life cycle of entities.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.