Re: [jpa-dev] [jakarta.ee-community] [jakartaee-ambassadors] Re: Java Re

[Christian Beikov <christian.beikov@xxxxxxxxx>]

Am 04.08.2022 um 21:15 schrieb Oliver Drotbohm via jpa-dev:
> Are you seriously suggesting we need a feasibility study first to find out whether we can load data from a database into instance of an immutable type? Efficiently? After we have had applications in production doing just that for years?
Just saying we should first experiment with records as entities in at 
least one JPA implementation before we start thinking about a 
specification.
> An entity lifecycle doesn't have to do anything with mutability. Conflating the two has been a deliberate design decision by JPA, probably not outrageously wrong back in the days. However, the world has moved on. The Spring Data code is open source, easy to find out what's going on there.
But that's my point, the entity lifecycle in JPA kind of requires 
mutability. So if we want to talk about really immutable entities like 
records (note that final variable are not writable), we should really 
check how that plays out.
> Who or what are these "newcomers"? What is a "mutability requirement"? 
> The spec requires user code to be mutable, sure. That has never meant 
> that implementations cannot go beyond the spec an work even if user 
> code doesn't meet those. I mean, isn't exactly that the USP of 
> individual implementations? 
Indeed it is one of the USPs of this model that individual 
implementations can go beyond. All I am saying (repeating myself) is 
that one implementation should first try out what it means to have 
records as entities to see how this could work out, because maybe the 
user model of some solution for this sucks and it might make more sense 
to introduce a new kind of managed type or whatever.
> No, no active record. Yes, the alternatives have deliberately decided 
> to opt-of the persistence context, change tracking approach as it is 
> both the cause for tons of developers scratching their heads and 
> complicating the implementation. But: what exactly is the point here? 
> That immutability is hard to support in these scenarios? Most of the 
> complexity with change tracking in entities is *because* they are 
> mutable. Immutable types don't need to be change tracked. They 
> simplify the arrangement, they don't complicate it. 
There are a few things that simply don't work well with records, which 
probably require new APIs, but other things might simply not work at 
all. Think about id generation, optimistic version increment or 
association cycles in entity models. Some JPA implementations require 
injection of certain fields through enhancement which can't really be 
done with records. Since proxying is impossible, we maybe need a few new 
APIs to do some stuff more efficiently. The list of possible pitfalls 
will probably get pretty long very fast.
> I didn't propose to throw the baby out with the bathwater. It's fine to take smaller steps. What I was a severe misrepresentation is claiming that all of this is completely unchartered territory, nobody has ever tried to do persistence into immutable types. I mean, Hibernate just recently shipped support for custom instantiators for embeddables. It takes a hand full of lines of code to make those work with records [0], there's been requests to put this support into Hibernate itself [1], you have the requests for support for records / immutable types here on this list. In this light, an "Oh, we need to wait for innovation and investigate whether this is even doable in the first place. Until that, we shouldn't do anything spec-wise." answer is a bit of a weird one, especially if it comes from the team of the strongest implementor in the first place. That's all I was saying.

Even though Hibernate had support for immutable basic-ish types 
(java.time, javax.money, etc.) for a long time and just recently added 
support for immutable embeddables as replacement for multi-column basic 
types, this doesn't mean that records as entities is a solved problem. 
On a side note, it's funny that you seem to have a working 
implementation for supporting records for embeddables with Hibernate, 
but didn't create a pull request for integrating this into Hibernate so 
far. Maybe if you would help JPA implementation teams like the Hibernate 
team with things that you care about, like records as entities or out of 
the box embeddable records support, also the standardization might 
happen faster. You know, everyone has their own priorities and only 
limited time to work on stuff.

It's just my personal opinion that the specification should evolve from 
something that is proven to work well. I can't speak for others from my 
team, but I think this kind of approach, to first innovate in products 
and then standardize what works well, is how things usually work. I 
personally wouldn't feel comfortable standardizing something before we 
know what needs to be done (in addition) to make it work well as a whole.

No idea what you intend to say when writing "especially if it comes from 
the team of the strongest implementor". If other JPA implementations can 
show that their implementation of records as entities works well 
(possibly with additional APIs) and they want to standardize this, I 
would personally support the standardization and would probably even be 
excited to work on this for Hibernate.

> Lucky you. And yes, because people just move on and use alternatives (jOOQ, MyBatis). I guess all of us (me explicitly included) do ourselves a favor to not consider our bug trackers a 1:1 reflection of the world but hopefully also see real-world applications from time to time. Most folks struggling with the tech we throw out either don't bother to report issues.

I'd really love to speak to people that move away from a JPA ORM with a 
managed entity lifecycle to an active record style library like (jOOQ, 
MyBatis) *just* because their favorite JPA implementation doesn't 
support records as entities. I really think you are overstating the 
importance of this particular aspect when it comes to the reasons people 
move away from JPA. We can start a different thread on this topic if you 
really want, but so far, I always saw that there were multiple reasons 
that lead people to move away. The most prominent reason I found, was 
that JPQL/HQL was lacking support for certain SQL features, which I 
started to fix step by step in newer Hibernate versions.

However, I can see more and more people that seem to be surprised about 
the concept of managed entities, so I might experiment with a dedicated 
API (similar to StatelessSession) and special kind of entity in 
Hibernate to simplify the model. I think that records might better fit 
into an API like this.

Regards,

Christian