Re: [hibernate-dev] Another @Access quandry
I have heard no more comments, so I will move forward with this as stated
earlier.
Additionally, I started working the a PoC for the idea of making this
resolution pluggable. Here is the initial stroke for the contract:
/**
* Contract responsible for resolving the members that identify the
persistent
* attributes for a given class descriptor representing a managed type.
*
* These members (field or method) would be where we look for mapping
annotations
* for the attribute.
*
* Additionally, whether the member is a field or method would tell us the
default
* runtime access strategy
*
* @author Steve Ebersole
*/
public interface PersistentAttributeMemberResolver {
/**
* Given the ManagedType Java type descriptor and the implicit AccessType
* to use, resolve the members that indicate persistent attributes.
*
* @param managedTypeDescriptor The ManagedType Java type descriptor
* @param implicitAccessType The implicit AccessType for the resolution
*
* @return The list of "backing members"
*/
public List<MemberDescriptor> resolveMembers(
JavaTypeDescriptor managedTypeDescriptor,
AccessType implicitAccessType);
}
On Sun, Mar 30, 2014 at 9:51 AM, Steve Ebersole <steve(a)hibernate.org> wrote:
I have pushed the latest topical guide:
https://github.com/hibernate/hibernate-orm/blob/master/documentation/src/...
Thoughts? Comments?
The "Attribute-level" section is still undone, but I think the rest of the
text lays out the expectations in that case (especially the "Extensions"
sections) ...
On Sat, Mar 29, 2014 at 2:06 PM, Hardy Ferentschik <hardy(a)hibernate.org>wrote:
>
> On 29 Jan 2014, at 17:59, Steve Ebersole <steve(a)hibernate.org> wrote:
>
> > Again to me this all comes down to 1 concept in JPA being used to
> represent 3 different things. That's never a good situation. So maybe
> internally we start representing all 3 distinctly.
>
> That's sounds like a good idea which would give us most flexibility. It
> might create a fair bit of more work initially though.
>
> --Hardy
>
>
>