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