HowTo Use EclipseLink features for implementing and using "UserTypes"

flybyray · October 1, 2018, 12:51am

Using types from JSR 354 like monetaryamount would be great.

What would be a supported way to use additional features from eclipse link?
Would it be possible and supported to use Read/Write Transformers?

github.com

otrosien/jpa-monetaryamount-example/blob/70e88a45ba7195ebc5d52ea1a92d013314e97caa/src/main/java/com/example/Product.java#L32


      
          @Entity
          @Access(AccessType.FIELD)
          @Table(name="PRODUCT")
          public class Product {
          
          
    @Id
              @GeneratedValue(strategy=IDENTITY)
              private Integer id;
          
          
    @Transformation(fetch=FetchType.EAGER, optional=true)
              @ReadTransformer(transformerClass=MonetaryAmountAdapter.ReadTransformer.class)
              @WriteTransformers({
                  @WriteTransformer(column=@Column(name="PRICE_AMOUNT", columnDefinition="NUMERIC(17,4)"), transformerClass=MonetaryAmountAdapter.WriteAmountTransformer.class),
                  @WriteTransformer(column=@Column(name="PRICE_CURRENCY"), transformerClass=MonetaryAmountAdapter.WriteCurrencyTransformer.class)
              })
              private MonetaryAmount price;
          
          
    // Unfortunately NOT using javax.money.CurrencyUnit, as JSON-Patching would fail.
              private Currency currency;
          
          
    public Product() {} // JPA

What would be the best way to display such multi column based types (composite or usertype) in edit or create views?

What would be the best way to generate a data model from a multitude of such types from a legacy database?
Maybe the legacy database has an association for the currencyunit in another table? Is it really useful to handle such things in the business logic?

— Please feel free to separate those questions into different topics.

flybyray · October 2, 2018, 4:00pm

Found some repositories which are currently under development, which show one way to go.

But this solution is using its own tables to store the data. That is a little bit awkward, because in most use cases money is tied to some entity and should be in a database row of this entity.
It will be very difficult to use such solution with legacy databases which most of the time have two columns like “PRICE_AMOUNT” and “PRICE_CURRENCY”.

krivopustov · October 3, 2018, 6:03pm

Hi Robert,

What would be a supported way to use additional features from eclipse link?
Would it be possible and supported to use Read/Write Transformers?

You can use all EclipseLink features to map your entity to the database.

What would be the best way to display such multi column based types (composite or usertype) in edit or create views?

In order to use attributes with non-standard types in CUBA metadata and Generic UI, you have to create a Datatype implementation for such type. See the docs and some examples here.

What would be the best way to generate a data model from a multitude of such types from a legacy database?

Probably it cannot be done in a fully automatic mode, because such fields have no apparent relations in the database.

flybyray · October 3, 2018, 9:21pm

@knstvk Thank you for those hints.

The background of my question is, I worked on a project with Play!-framework (version 1), therefore I am used to think about JPA the Hibernate way. The project was an “island” but now needs to integrate with an old legacy database of another application. It worked very well, but I cannot maintain the code in future and someone else would jump into ‘homegrown’ integration work of several tools - activiti(bpm), liquibase, birt(reporting), a crud module. There is some outstanding todo on the ui mainly crud part (browsing large data, real paging is needed). At all the code base is not maintainable for a new person, as it is less documented (ui and templates are a mess). For that reason I search for some way to migrate to some other framework. The CUBA-Plattform is the best candidate from my perspective.

The fields have an apparent relation - column name prefixing with IDUnit. For example a currency withvalue in column Sollmiete and unit in column IDUnitSollmiete. Such prefixing or suffixing is quite regular for legacy dbs to specify some column relation.
For that reason we introduced an own annotation @UnitColumn and an enhancer took it to produce hibernate and play-binding annotations (usage: RentContract.java - part of a decompiled enhanced class).
The currency type parameter in org.hibernate.annotations.Type is contributed through
an org.hibernate.boot.model.TypeContributor (SysUnitTypeContribution.java), which contributes several units of measurements.
Units of measure (UOM) do not change often and for that they are loaded from enumeration like structures, but even from databases. Therefore the unit of an UOM-attribute in an entity most often has just a reference to an external defined unit. In the case of that project it is a sysUnit table. The application needs just some fields like id and symbol from that table. With a simple DTO, enumeration structures will be created at applciation boot time.
The unit only is a org.hibernate.usertype.UserType (get|set).
The unit of measure a org.hibernate.usertype.CompositeUserType (get|set).

In the ui it looks like that.

A nicer and similiar (but more static) CurrencyField in CUBA needs to be improved somehow.

I think than I need to use both mechanisms to archive that goal. I guess I need to use MetaProperty with its related parameter to reference all db fields.

https://www.martinfowler.com/eaaCatalog/money.html
But now we have JSR 354 and probably support for other units and conversions as well. Would be nice to have a common way to persist them easily.

Maybe some addons like currency-addon will be generalized and integrated in the cuba-core someday.

flybyray · October 5, 2018, 7:08am

But without support of CUBA Studio. I need to write database update scripts myself. as it will not inspect the Column Annotations from WriteTransformer.

Would it be possible to extend that part of CUBA? What would be a good starting point?

krivopustov · October 10, 2018, 6:57am

Robert,

Thank you very much for the detailed explanation of your use case, it’s very valuable for us and will help us planning the road map. I’ve created an issue so we’ll return to this problem next year after launching version 7.

For the time being, the only option for you is to implement the currency support manually in your project. Please let us know if the framework or Studio prevents you from doing it - we’ll try to fix it in high priority.