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 On Fri, Mar 28, 2014 at 3:18 PM, Steve Ebersole <st...@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 > <emman...@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 <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
