new project for vavr-hibernate

[chb0github]

Would be great from an adoption standpoint to have ready-to-go hibernate support.

[danieldietrich]

How would that support look like? Brainstorming welcome!

Generally we do not bake dependencies to 3rd party libs directly into the core Vavr library. Supporting hibernate (in the one or other way) requires us to create a new project. That's the only constraint.

[nfekete]

@chb0github That's an interesting idea. Did you try to investigate whether it is actually possible?

To me it seems that Hibernate (and JPA providers in general) are pretty much tied to the Java Collection API. For example, they provide special implementations of the Java Collection API interfaces Set, List, Map, etc: PersistentSet, PersistentList, PersistentMap, and so on.

I didn't look into this recently, but I remember from a few years ago that Hibernate didn't provide the customization capabilities required to use different implementations for these persistent collection classes. With all the features JPA providers support, like lazy association fetching, these classes are designed with mutability in mind. Without active customization support on this level from the persistence provider, implementing these kind of things could prove really difficult.

[chb0github]

My confidence that this is possible is nearly 100% - I have done it in the past. There are 2 different ways to do it:

One is with a UserType which is generally applied on the field being bound with @Type( VavrType.class) - The basics are: Given a result set, construct the result to be bound to the object field and return it - should be no problem to integrate.

Option 2 is anTypeDescriptor. I have never used these.

The option to use is the one that requires nothing more than the dependency being dropped in and that's it. We should model it on how hibernate support for hibernate-java8 was implemented. It takes care of things like Instant which are immutable as well as Optional and Stream.

Once a strategy is developed a new repository would be created that just has necessary hibernate dependencies discovered at runtime so it isn't version bound - these 2 approaches seem to have been around forever so that's a safe approach for portability

[chb0github]

As I thought about it more, ideally such a package would support options 1 and 2 so that the user may choose.

[danieldietrich]

@chb0github I added a new repository vavr-io/vavr-hibernate and a new developer team to the Vavr organization. May I add you to the Vavr organization and to the new team in order to start with vavr-hibernate?

[chb0github]

Yeah, that'd be great! Thanks

[chb0github]

Not sure if I somehow forgot to mention:

Yeah, sure. Sign me up

Christian On Fri, Jun 30, 2017 at 12:39 AM Daniel Dietrich notifications@github.com wrote:

@chb0github https://github.com/chb0github I added a new repository vavr-io/vavr-hibernate and a new developer team to the Vavr organization. May I add you to the Vavr organization and to the new team in order to start with vavr-hibernate?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vavr-io/vavr/issues/2022#issuecomment-312198257, or mute the thread https://github.com/notifications/unsubscribe-auth/ABaI0Kobhdl3LfpS7GJrsSNCq-_YkDReks5sJKYbgaJpZM4OI4Jp .

[danieldietrich]

@chb0github awesome, thank you! I've overseen your replies, my inbox is still too full after vacation 😅

[danieldietrich]

We created it, now we need to ramp it up. Ticket can be closed.