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

[Steve Ebersole]

On Fri, Mar 28, 2014 at 7:06 AM, Hardy Ferentschik <hardy at hibernate.org>wrote:

>
> On 27 Jan 2014, at 23:54, Steve Ebersole <steve at 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.
>
> Which SPI exactly?
>

org.hibernate.engine.spi.SessionFactoryImplementor#getCollectionPersister(String
role)


> 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?
>
> I like it. I have been wishing more than once that there would be a
> clearer distinction.
> As you say, some existing code is very fugly due to the existing dot
> notation.
>

Even better, internally I have now Object-ified the notion of path and
role: AttributePath and AttributeRole.