To wrap this up..
The most important part for me is being able to identify the point between
the "attribute base" and the "attribute path". If we just use a
separate
delimiter there, that's enough for me. Since one of us has a preference
for using dots within the "attribute path" part (and its irrelevant to me),
I'll go with that. So:
org.h.SomeEntity#nv.to.hell
+1 for that.
You might also consider to use "::" as the delimiter between base and path:
org.h.SomeEntity::nv.to.hell
"::" is the syntax for method references in Java 8 and it may possibly be
used for field references as well in a future Java version. So in some way
it may be nice to resemble that.
--Gunnar
On Fri, Mar 28, 2014 at 3:18 PM, Steve Ebersole <steve(a)hibernate.org>
wrote:
> What we choose as a separator after the "pivot" is irrelevant to a
degree,
> especially in terms of the compatibility concern. I think you understood
> that, just being clear. Meaning that calls like:
>
> sessionFactoryImplementor.getCollectionPersister(
"org.h.SomeEntity.nv.to.hell"
> )
>
> will fail whether we use "org.h.SomeEntity#nv.to.hell" or
"org.h.SomeEntity#nv#to#hell"
> as the role key.
>
> As for "being natural", we'll agree to disagree. But Java has no
such
> notion as attributes so arguing about what is more natural in how Java
> represents attribute paths is a bit moot imo. Were these all *accessible
> fields*, then sure the code to access them chained would use 'dots'.
But I
> think its pretty plain to see how in the call I listed above:
>
> sessionFactoryImplementor.getCollectionPersister(
"org.h.SomeEntity.nv.to.hell"
> )
>
> the use of '.' locks you into never being able to programatically
> parse/understand that String structural, which I think is just very
> limiting in many places.
>
>
>
> On Fri, Mar 28, 2014 at 1:44 PM, Emmanuel Bernard <
emmanuel(a)hibernate.org>wrote:
>
>> No strong feeling about it.
>> It will break the OGM dialects that make use of the collection role
>> though. So we need to anticipate.
>>
>> To me . looks more like the code being used and is a natural notation
>> even beyond Java. But I get that # offers some additional info.
>> Have you considered?
>>
>> org.h.SomeEntity#nv.to.hell
>>
>> I think that would have my preference actually.
>>
>> On 27 Mar 2014, at 23:54, Steve Ebersole <steve(a)hibernate.org> wrote:
>>
>> > This is a bit of a potentially insidious one. Not the best way to
start
>> > off a discussion, I know :)
>> >
>> > The premise is this... Until now Hibernate has represented attribute
>> roles
>> > using dots. For an attribute named 'department' on the
>> com.acme.Employee
>> > entity, the role would be "com.acme.Employee.department". In
terms of
>> > embeddables, say Employee had an 'address' embedded with its own
>> attributes
>> > like 'city'. Then, the full role for 'city' would be
>> > "com.acme.Employee.address.city".
>> >
>> > As you can start to see the dots here are completely indistinguishable
>> in
>> > terms of those which define the package/class and those which identify
>> the
>> > attribute "path".
>> >
>> > So one of the things I started playing with in 5 is to replace the
>> > separators used in attribute paths to use '#', such that
>> > "com.acme.Employee.address.city" would instead be
>> > "com.acme.Employee#address#city". This makes the role fully
parseable
>> > which is actually useful in quite a few situations. And it REALLY
>> helps in
>> > things I have just started working on like storing metadata for
>> composites
>> > (embeddeds/embeddables) on the SessionFactory, which is the first step
>> in
>> > support for some cool new features around embeddables like
discriminated
>> > inheritance support.
>> >
>> > However, there is a minor drawback. Like all attributes, collections
>> have
>> > a role. Unfortunately the use of '.' in their role Strings leaks
into
>> the
>> > SPI in terms of locating the CollectionPersisters.
>> >
>> > So the question is whether to continue with this path of replacing the
>> use
>> > of '.' with '#' for attribute path separators. The
drawback is
>> > unfortunate. The benefit is very nice, but I can't really say it is
>> > required atm.
>> >
>> > Votes? Thoughts?
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev(a)lists.jboss.org
>> >
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev