In my opinion the definition of the Entity Class (JPA Spec - Chapter 2.1) should be updated. Some sort of immutable Entity Class could be introduced for java records.
Hi,
Off the top of my head, I would see Records being used for two main purposes: DTO/projections and attributes.
For DTO/projections, I don't think there is much to do as JPA already allows returning objects in queries with the syntax "select new my.company.MyDTO(e.attribute, e.anotherAttribute)
from MyEntity e". I don't think Records behave so much differently than regular classes that they would need special treatment.
For attributes, I think it's a bit more complicated as there are 2 different cases depending on where you would put the mapping information.
If you have access to the Record source code, you could annotate the Records components with @Column, @Basic, etc. as components accept annotations which target fields.
If you don't have access to the source code (or if you want to keep mapping separated from the code), you could declare the mapping in orm.xml as Records could be considered as
a kind of immutable embeddable objects (and it's already possible to declare embeddable mappings in orm.xml).
Anyway, the JPA provider would need to detect that the object is a Record and construct it appropriately (Record constructor for Records vs. default constructor + setters for regular
embeddables).
Everything should still work when nesting Records and mixing regular embeddables with Records.
There is always the possibility to use AttributeConverters for single-column Records. For now, AttributeConverters can't be used for multi-columns objects and you need to resort
to vendor-specific adapters. This is a limitation that should really be addressed in the next JPA version.
A third purpose for Record would be for immutable entities: entities which are fully constructed (including their id) from their constructor and never updated. Hibernate can already
mark an entity as @Immutable which can improve performance as no dirty checking is needed for those entities.
Regards,
Xavier
Hi Reza
I think a scenario based PoC can be done and check the outcomes and make fixes if it doesn’t represent the data in a desired way. Generally in a business
app, most of the times the Java Records will be as DTOs as you said.
Do you or anyone else want to work with me on an analysis from the end user standpoint?
I don't think this is that straightforward and will require some level of scenario outlining. In particular, it is still unclear to me how Java Records fit into
an overall application domain model vis-a-vis JPA entities and embeddables. It is possible the only use case for Java Records are as DTOs, in which case a possible set of enhancements could be just some relatively simple converters. There may even be space
here for a vendor neutral small utility library and nothing in JPA itself (maybe part of DeltaSpike).
Jakarta EE Ambassador, Author, Blogger, Speaker
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
Date: 4/24/20 1:29 AM (GMT-05:00)
Subject: Re: [jpa-dev] Java Records Alignment?
Aren't single-valued records somehow already supported by writing custom AttributeConverters?
For multi-valued records, a enhancement proposal for AttributeConverters exists:
On 23 Apr 2020 12:57 a.m., Lukas Jungmann <lukas.jungmann@xxxxxxxxxx> wrote:
Hi,
On 4/18/20 8:20 PM, reza_rahman wrote:
> Lukas,
>
> I just wanted to quickly ask - is it sensible to file an issue on Java
> Records alignment with JPA?
Yes, it is, feel free to go ahead with that.
thanks,
--lukas
If it is, I will see if someone else from
> the community can research this and file a preliminary issue. My IP
> chain with Microsoft and Jakarta EE is still murky, so it is best I
> don't enter too many details too frivolously myself.
>
> Reza Rahman
> Jakarta EE Ambassador, Author, Blogger, Speaker
>
> Please note views expressed here are my own as an individual community
> member and do not reflect the views of my employer.
>
> _______________________________________________
> jpa-dev mailing list
> jpa-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jpa-dev
>
_______________________________________________
jpa-dev mailing list
jpa-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jpa-dev
_______________________________________________
jpa-dev mailing list
jpa-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jpa-dev
