hohwille
commented
6 years ago However, your PRs are always a lot of effort to review due to the fact, that they do not concentrate on a specific task
Indeed I removed some empty JavaDoc lines from classes I came along on my way that are not directly related. However, even though it might not look like in the first place: All I did is to add this feature and then create a test for the feature. The test itself requires a lot of implicit changes what is IMHO what you are talking of here. In the past I added features without JUnits but I learned that this is even worse so I now always add tests. In my PR I added a lot of explanation why I had to do all these related changes. Of course you are right that this change is then hard to review. Anyhow I still would not see how to separate this properly into multiple PRs that make sense of its own. Maybe for #627 your feedback applies however... Thanks for your feedback and review. I would love to see some more discussion with others before we finally decide. IMHO if we merge this we have to ask ourselves if this is the new recommended way to deal with relations. If so we would change cobigen templates accordingly, etc.
amarinso
maybeec
With OASP4J so far references to other entities (in TOs) are represented as
Long. This is not type-safe, not expressive and self-descriptive and finally error-prone: https://github.com/oasp/oasp4j/blob/develop/samples/core/src/main/java/io/oasp/gastronomy/restaurant/salesmanagement/logic/api/to/OrderPositionEto.java#L17 Without further documentation or guessing from names you can not determine the type of the linked entity as you only see aLongvalue. Even worse to map such a reference back from TO to entity we are using this "hack": https://github.com/oasp/oasp4j/blob/develop/samples/core/src/main/java/io/oasp/gastronomy/restaurant/salesmanagement/dataaccess/api/OrderPositionEntity.java#L84 While this "hack" is working in 95% of the cases it relies on JPA/hibernate internal magic and I faced the ugly 5% cases in my customer project where this "hack" is simply not working and you end up with complex hibernate stacktraces.To address this and improve OASP4J this PR introduces a generic interface
Ref(used as shortcut for Reference as the name will be spread around the code-base and should therefore be short) and a standard datatype implementationIdRefthat is just a wrapper for the referenced ID asLong. So instead ofYou can now write
What makes your reference type-safe and expressive. Starting with Java8 type-inference you can easily write
this.orderId = IdRef.of(myOrder);. As a solution to avoid the "hack" mentioned above I introducedJpaHelper. It still requires some static "hack" internally but solves the hibernate issues so it works in 100% of the cases (though it will cause problems if you have multipleEntityManagers in a single app - what is rather discouraged but might also happen). However, such projects are still free to use the old "hack" instead. One could also implement a tweaked version ofJpaHelperthat does exactly this instead.Example usage (created for JUnit testing): https://github.com/hohwille/oasp4j/blob/fd13d104a386a164ba068cea834a4b55ab1bda7d/modules/jpa/src/test/java/io/oasp/example/component/dataaccess/api/FooEntity.java#L61
Test-Cases:
As an enhancement I could create a spring-boot-starter for
JpaInitializerasoasp4j-starter-jpa. See: https://github.com/hohwille/oasp4j/blob/fd13d104a386a164ba068cea834a4b55ab1bda7d/modules/jpa/src/test/java/io/oasp/example/TestApplication.java#L18