[hibernate-dev] Another @Access quandry

[Steve Ebersole]

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 at hibernate.org> wrote:

> I have pushed the latest topical guide:
> https://github.com/hibernate/hibernate-orm/blob/master/documentation/src/main/asciidoc/topical/accesstype/AccessType.adoc
>
> 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 at hibernate.org>wrote:
>
>>
>> On 29 Jan 2014, at 17:59, Steve Ebersole <steve at 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
>>
>>
>>
>