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