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