Re: [hibernate-dev] Attribute paths and '.' versus '#' as separator

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&gt;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&gt; 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 > >