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

[Steve Ebersole]

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 at 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 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.
> >
> > 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>