Sorry I could not look at it until now. I looked at what's on master and it
looks accurate to me.
I know you find the logic spread over too much. But the way it is handled is
consistent and in the same spirit of similar-ish concepts (AttributeOverride,
PropertyHolder, property navigation etc).
https://github.com/hibernate/hibernate-orm/pull/591
On Thu 05 Sep 2013 10:06:14 PM CDT, Shaozhuang Liu wrote:
> I can give it a try
> -
> Best Regards,
>
> Strong Liu
> http://about.me/stliu/bio
>
> On 2013Sep 6, at 8:15 AM, Steve Ebersole wrote:
>
>> I have something mo
I can give it a try
-
Best Regards,
Strong Liu
http://about.me/stliu/bio
On 2013Sep 6, at 8:15 AM, Steve Ebersole wrote:
> I have something mostly working and not causing regressions. Its quite
> fugly, but I blame that on binders and hcann :)
>
> I'd really like to
I have something mostly working and not causing regressions. Its quite
fugly, but I blame that on binders and hcann :)
I'd really like to do a pull request for this one and have y'all take a
look. But at the same time I'd also really like to do the 4.3 Beta4
release tomorrow. Anyone familiar
On 2013Sep 5, at 12:43 PM, Steve Ebersole wrote:
> Stepping through the code showed me that PropertyHolder#addProperty will
> not be useful here. Its called after the corresponding
> SimpleValueBinder#setType call. Really not understanding how these are
> intended to work.
>
> I have some o
On Thu 05 Sep 2013 11:52:22 AM CDT, Shaozhuang Liu wrote:
>> Also, I am not sure that iterating properties yet again is a great idea.
>>
>> One alternative I had considered was to hook this in with
>> PropertyBinder, where it calls SimpleValueBinder. That needs to happen
>> anyway; the plan was to
I really need someone who actually understands the AnnotationBinder and
commons-annotations stuff to look at this and help me find the plan for
applying attribute converters.
From what I can tell, PropertyHolder is the proper place to perform the
resolution of which converter to use because th
Stepping through the code showed me that PropertyHolder#addProperty will
not be useful here. Its called after the corresponding
SimpleValueBinder#setType call. Really not understanding how these are
intended to work.
I have some of the normalization working, hooked into PropertyHolder
construc
I am still a bit confused on how to apply the normalization to make sure
it happens in the proper order.
Let's look at:
@Entity
class Person {
...
@Embedded
@Convert( attributeName="city", converter=Converter2.class )
public Address homeAddress;
}
@Embeddable
class Address
On Tue 2013-09-03 17:22, Steve Ebersole wrote:
> 2.a) It seems like there are times when
> org.hibernate.cfg.AbstractPropertyHolder#parent would be useful for
> what I need to do. But there appears to be times when this is null.
> For entity mappings (ClassPropertyHolder) thats fine. But for the
Gah, stupid.
Its the declared/non-declared status of the method/field that is
important here, not the annotations...
On Tue 03 Sep 2013 11:08:16 PM CDT, Steve Ebersole wrote:
> FYI, unless I hear otherwise:
> https://hibernate.atlassian.net/browse/HCANN-56
>
> On Tue 03 Sep 2013 11:01:02 PM CDT,
FYI, unless I hear otherwise:
https://hibernate.atlassian.net/browse/HCANN-56
On Tue 03 Sep 2013 11:01:02 PM CDT, Steve Ebersole wrote:
>
>
> org.hibernate.annotations.common.reflection.XAnnotatedElement
>
> On Tue 03 Sep 2013 05:22:22 PM CDT, Steve Ebersole wrote:
>> After looking through this s
org.hibernate.annotations.common.reflection.XAnnotatedElement
On Tue 03 Sep 2013 05:22:22 PM CDT, Steve Ebersole wrote:
> After looking through this some more, I think what you say could
> almost work. But:
>
> 1) Still need a way to determine the declarer of a property rather
> than just blind
After looking through this some more, I think what you say could almost
work. But:
1) Still need a way to determine the declarer of a property rather than
just blindly accepting XProperty.getAnnotation(Convert.class). This is
needed for the Super/Sub MappedSuperclass/Entity case in my initial
Also, unless we have some normalization rules, my point was that we
literally cannot do this today in annotations.
Essentially the bug-a-boo is composites (and maybe collections as
composite via allowance of "map.", etc). We'd essentially have to
normalize all paths for converters to be the co
The point is that, for converter, sometimes "the XML winning" isn't
"the XML winning". What I mean is that just like with @Convert,
can exist at the or level.
So given your example:
@Entity
public class Sub {
...
@Convert( converter=Converter1.class )
public String getIt() {
Yes I get that but JPAOverriddenAnnotationReader is only about reading
the XML and converting it into annotations.
I understand that implementing the rules based on the annotations is
more complex than annotation override.
On Fri 2013-08-30 8:44, Steve Ebersole wrote:
> Its not that easy. This
Its not that easy. This is not as simple as AttributeOverride. The
rules here are much more complex (or convoluted, depending on your
perspective). An AttributeOverride always overrides. The is just not
the case here with converters. Plus how AttributeOverride works does
not need to vary f
On Fri 2013-08-30 6:27, Steve Ebersole wrote:
>
> On Fri 30 Aug 2013 06:05:37 AM CDT, Emmanuel Bernard wrote:
> >>
> >>
> >>2) The 'declaringClassName' passed in to SimpleValueBinder#setType
> >>is Sub. So maybe we can leverage that. But
> >>org.hibernate.cfg.annotations.PropertyBinder#makeProper
On Fri 30 Aug 2013 06:05:37 AM CDT, Emmanuel Bernard wrote:
>>
>>
>> 2) The 'declaringClassName' passed in to SimpleValueBinder#setType
>> is Sub. So maybe we can leverage that. But
>> org.hibernate.cfg.annotations.PropertyBinder#makePropertyAndValue
>> (the main caller of this method) has explici
On Thu 2013-08-29 16:16, Steve Ebersole wrote:
> Ok, so given the initial Super/Sub setup, what we get in
> SimpleValueBinder#setType is this:
>
> 1) The XProperty passed in is defined as follows:
> a) It is a JavaXProperty speciffically
> b) Its 'annotatedElement' attribute (not exposed) is the
>
Ok, so given the initial Super/Sub setup, what we get in
SimpleValueBinder#setType is this:
1) The XProperty passed in is defined as follows:
a) It is a JavaXProperty speciffically
b) Its 'annotatedElement' attribute (not exposed) is the
java.lang.reflect.Field for the Super#it field.
c) Interes
2013/8/29 Emmanuel Bernard
> On Thu 2013-08-29 14:22, Steve Ebersole wrote:
> > Given an XProperty, is there a way to ask for annotations which are
> > defined only locally on that declared property (not on any super
> classes)?
>
> I believe that is what XProperty will give you.
> The list of XP
So actually what happens is that the XProperty is from the superclass.
This goes back to SimpleValueBinder, and the attempt to hook
AttributeConverter resolution into that code. Specifically in
org.hibernate.cfg.annotations.SimpleValueBinder#setType when we are
passed the XProperty. Maybe thi
On Thu 2013-08-29 14:22, Steve Ebersole wrote:
> Given an XProperty, is there a way to ask for annotations which are
> defined only locally on that declared property (not on any super classes)?
I believe that is what XProperty will give you.
The list of XProperty of a given XClass is computed fro
Given an XProperty, is there a way to ask for annotations which are
defined only locally on that declared property (not on any super classes)?
Basically given this situation:
@MappedSuperclass
public class Super {
...
@Convert( converter=Converter1.class )
public String getIt() {
26 matches
Mail list logo
