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

[Christian Beikov <christian.beikov@xxxxxxxxx>]

Am 11.08.2022 um 14:42 schrieb Oliver Drotbohm via jpa-dev:
> I guess it makes sense to point out that the discussion didn't start with "entities as records" but records support in general.
Maybe it's just my interpretation, but to me, your previous emails made 
the impression that you were saying "records as entities" is a thing we 
have "figured out" for JPA. Now that we have made clear that your 
proposal is actually about supporting records for embeddables, which is 
something we (almost out of the box) support in Hibernate already, we 
can continue to have constructive discussion, as we know that it's 
feasible to do this. Note that your jMolecules integration doesn't work 
if the owning entity uses Access.PROPERTY. This is where deeper support 
for records in Hibernate is needed.
>  From that there are is a lot of ground to explore that's much easier to tackle than the admittedly rather specific "records for *JPA* entities" as that drags the "the JPA lifecycle expecting mutability" into the picture, which should be an orthogonal topic. That maybe making "entities as records" a non-starter *for now* shouldn't prevent us from exploring what else can be done with records in the spec already, especially as it has been done in other contexts for a while already.
Sure. Please propose where you think records might be useful other than 
for embeddables. Hibernate will certainly look into records as entities, 
and after we gained some experience with this, we can revive the 
discussion about standardization.
> A much lower hanging fruit here is support for immutability for embeddables for example. Once you have immutability in general sorted out, support for records often is just a matter of detecting accessor methods properly, i. e. basically comes for free. At least that's the experience we made in Spring Framework / Data. For the former, we added support for Kotlin data classes and immutable Java types in the area of data binding, totally unrelated to records. The support for them then was just a change in the PropertyDescriptor detection.
Agreed, we can start thinking about adding a section in the spec that 
says records as embeddables should be supported. Supporting constructor 
injection (that's what this ultimately comes down to) for other types 
out of the box is a bit tricky though. Determining which field/property 
belongs to which parameter of a "canonical constructor" is something 
which can be done usually by bytecode analysis, but I think that 
annotation support would be better here, so maybe we can talk about 
adding ElementType.PARAMETER as target for some annotations, as well as 
introducing an optional annotation for parameters, so we can map them to 
fields/properties.
> I agree it does as it is designed right now. But "having to 'set' a database-generated id on an entity" doesn't have to necessarily mean "call a setter and change the instance" but could also mean calling a method that will return a fresh instance with new state. In Spring Data, we've settled on wither methods for that, which the user have to expose if they want immutability plus framework-driven alteration of their instances.
Exactly. My point is just, that this will probably require new APIs, 
which we have to prototype in a JPA implementation.
> I guess you know from experience that it's a whole different story to implement something in your own little world, in which you oversee context of application, tests and build or whether you have to integrate all of that into someone else's park. Time is a scarce resource for us / me, too, and when I was working on that particular integration I thought the rest of that time was better invested in taking H6 for extensive battle tests in our builds and, by that, help you polish out some rough edges that way.
> That's a funny thing to say after all the time we spend on reports we shared taking H6 for a ride to get it to work in Spring Data JPA based applications. Does it make sense we assume that we each make our own judgements where we spend our time on? I don't think accusing the other of not doing helpful things at all or the wrong ones is helpful.
Sure, I understand all of that and we are grateful for all the reports 
and reproducers. My goal was to point out that, if our pace of working 
on features/bugs isn't good enough for your timeline, you can help us 
and in order to get stuff faster.
> I might read this wrong but to me you seem to again be suggesting that we don't know whether this "something" (any kind support for records / immutable types) works *at all*. Which is simply not true. I hope you understand that this might rub folks that have made this stuff work – even if that's persistence contexts (pun intended) other than JPA – the wrong way.
See above - my assumption was you were talking about records as entities.
> With that, I acknowledge that to the folks writing JPA applications a feature that does not exist in Hibernate basically doesn't exist at all. You have – and I say this with a uttermost respect – a lot of weight in the entire arrangement. This list – and thus the spec – is primarily driven by implementors and I think it needs a strong opinion from the consumer side from time to time. That's why it's a bit of a pity if you resort to "Why don't you actually submit a PR?" when in fact we spent a significant amount of time helping you iron out issues with the latest release. In fact, I enjoyed that work quite a bit as it showed how different parties can help moving the overall community forward. Dismissing all work just because it's not pull requests feels a bit disappointing in that regard.
Like I wrote before, we are grateful for that help. Like for your team, 
our teams time is scarce as well and if something doesn't fit our 
priorities right now, the only thing I can tell you is to "submit a PR", 
unless you want to wait. I understand that you'd like to influence our 
priorities to align better with yours. We really try to make everyone as 
happy as possible, but sometimes you just have to take matters into your 
own hands if you care about them, which you seem to have done for the 
EmbeddableInstantiator. Now that I have seen this code, I actually 
started working on this and Hibernate might support records out of the 
box soon.
> I don't think anybody stated that. One's favorite implementation doesn't even play into this, because currently none exist that'd support this. It's very well likely that this is my personal bubble, but with the (second) advent of DDD I definitely see more people caring about domain models and the persistence of those (note: not entities derived from database tables).
>
> Unless JPA does a decent job of persisting those models OOTB without being too limiting in terms of the model design, teams resort to a domain model + a dedicated persistence model, with the latter often persisted with much "simpler" persistence mechanisms. "Simpler" meaning to the developers that they feel like they're more in control of what's happening under the covers. The fact aside, that I personally think that they often misjudge that tradeoff.
Personally, I think that having a separate persistence and domain model 
is the way to go. That's why I implemented Blaze-Persistence 
Entity-Views, which can be used as smart DTO/domain-model, that 
automatically synchronizes with the persistence model. JPA requires 
bi-directional mappings, and I think certain read-projections are simply 
a bad fit for a persistence model, that's why a separate domain model is 
IMO necessary.


Regards,

Christian