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 <st...@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
