search

jakartaee / data

Data-API
Apache License 2.0
82 stars 27 forks source link

clarity and uniform language around entity fields/properties #393

Closed gavinking closed 5 months ago

gavinking commented 7 months ago

It's not currently clear whether the Jakarta Data provider accesses the persistent state of an entity via property accessors, or direct field access, or both. And this is reflected in the fact that the spec does not currently have very uniform language in this area.

Many years ago, we used to use property-based access in Hibernate code examples, but I think it's safe to say that's not what most Hibernate or JPA users do today. So, honestly, I guess I would be fine to just talk about fields everywhere. On the other hand, Jakarta Persistence goes out of its way to allow both things, so I guess it would be at least a bit more consistent for Jakarta Data to also recognize this.

Whatever, I think we definitely need to say something much more explicit about this in chapter 3, and make sure the language is consistent across the spec.

beikov commented 7 months ago

I'm not sure where Jakarta Data would have to access state of an entity, but please note that accessing entity state through properties/getters is preferred for "external code". Lazy loading is one reason, but there was another that currently eludes me, though I will add it as a comment once I remember it again.

gavinking commented 7 months ago

See https://github.com/jakartaee/data/pull/392/commits/3bc4dc227b7405540a4401adfa31bcd6926170cc.

beikov commented 7 months ago

FYI, direct field access can't work when proxies are involved, unless some sort of extended bytecode enhancement is done that replaces all field accesses with special accessor methods. In Quarkus we can support field access for Hibernate ORM entities because we have this enhancement enabled for the whole code base. Not sure what you can make of this for the Jakarta Data spec, but just wanted to let you know about the restrictions/specialties of field access.

gavinking commented 7 months ago

I don't know what you mean. The provider can always read and write fields by reflection. This is required of all JPA implementations, and was implemented in Hibernate long before Hibernate had any bytecode processor.

gavinking commented 7 months ago

[It's true that a provider which uses proxies to do lazy fetching might want to say something like "fields should be private", but that restriction would be required independently of the access mode, and is orthogonal to this discussion. It's not affected by the access mode at all.]

beikov commented 7 months ago

I don't know what you mean.

You wrote:

It's not currently clear whether the Jakarta Data provider accesses the persistent state of an entity via property accessors, or direct field access, or both.

So unless the Jakarta Data provider == JPA provider, then data would have to be accessed through property accessors by the Jakarta Data provider, though I don't fully understand what data the Jakarta Data provider would have to access. Maybe it's just a misunderstanding, but either way, I wanted to point out these restrictions regarding field access.

gavinking commented 7 months ago

When you hand an entity instance to Jakarta Data, the provider has to be able to read its field values somehow.

Similarly, when Jakarta Data reads an entity from the database, and instantiates an entity class, it has to set the fields of the entity somehow.

That's all I'm talking about here.

gavinking commented 5 months ago

This was done a while ago, it's in section 3.1.2 of the spec.