| Re: [jpa-dev] [jakarta.ee-community] [jakartaee-ambassadors] Re: Java Records and Jakarta EE |
> On 9. Aug 2022, at 15:06, Christian Beikov <christian.beikov@xxxxxxxxx> wrote: > > Just saying we should first experiment with records as entities in at > least one JPA implementation before we start thinking about a > specification. I guess it makes sense to point out that the discussion didn't start with "entities as records" but records support in general. 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. 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. > 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. 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. > 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. Agreed. Again, records as entities kind of being the end boss here with the implications described above. > 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. See inline above. > 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. 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. > 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. 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. > 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. 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. That said, I've witnessed and helped working on a couple of JPA features that were introduced *with* prior art and I don't think I can say I can correlate that fact to the success or non-success of that particular feature. > 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. 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. >> 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 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. > 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. I guess that's the nature of the bubbles we each live in. Maybe that's something that could be taken into the next JakartaEE developer survey? Cheers, Ollie
Attachment:
signature.asc
Description: Message signed with OpenPGP