|
|
|
[
Permlink
| « Hide
]
Ken in nashua - 09/Jul/07 05:07 PM
Please refer to revision 554 for working logic.
I see, I misinterpreted the logic.
But now that I do understand it, it doesn't look right to implicitly override the hibernate behavior. I think you should introduce a new annotation to handle this. This way the user would need to explicitly tell Trails to use an OwningObjectReferenceDescriptor using this new annotation. Here you have information about creating a your own annotation: http://www.trailsframework.org/Adding+Custom+Editor Alejandro, can you post usage of this annotation as you see it? An example.
I felt that the implicit overriding was ok and could always be extended thereafter. I'd like get a feel for what you had in mind for usage and make a decision fromt there. Thanks. Owner-
Ok, so if on owner we have @OneToOne(owner=true, association=false) Then this guy is the owner and HibernateDescriptorDecorator should allocate OwningObjectReferenceDescriptor right? @OneToOne(owner=false, association=true) Then this guy is the association and HibernateDescriptorDecorator should allocate ObjectReferenceDescriptor right? Not sure so... Then we check for mappedBy... if that exists then we drill into the class/reflection structures to get the actual class property within the owning object of the class being decorated. NOTE: The class currently being iterated by decorator could be owner or association. So I don't think tagging the owning class as owner will help because it is the association we are decorating. Is it ok if we stay with the original logic? Alejandro, The impact to the working code I checked in is too broad and spans too many classes. I feel like I am being sent back to first week of April to re-write it all. Support for the original logic is removed.
Since the code is now your version, can you implement/patch? Ok I am trying to see your code thru to the solution.
It appears this block is not working is mappedBy is not found. The soft OneToOne editor is not launched. Maybe your code is good and the editor bug is in the editor logic? IPropertyDescriptor descriptorReference = try Shouldn't descriptorReference be PropertyDescriptor when allocating OwningObjectReferenceDescriptor?
IPropertyDescriptor descriptorReference = I see your allocating it by default at the top. Original logic I believe allocated PropertyDescriptor and then added the extension from there. I cannot comment on the significance of the difference. I am just trying to understand why the editor is not coming up like it should. Also, I removed all my mappedBy attributes from my pojos and the hard editor keeps coming up. Alejandro, your version does not support inverse.
If you could patch this to work I would be greatful. thanks
Yes I can, but it may take a while since I don't have any free time these days.
No, the wrong logic is only in HibernateDescriptorDecorator.decorateAssociationDescriptor every thing else is fine.
No, HibernateDescriptorDecorator.decorateAssociationDescriptor is wrong. "mappedBy" is always "" when is not declared, so if there is a OneToOne annotation, the descriptor always end up decorated by an OwningObjectReferenceDescriptor.
Nope, OwningObjectReferenceDescriptor is an extension now and it doesn't have all the information it needs to work. The information missing in the extension comes from the ObjectReferenceDescriptor. They complement each other.
Should it? Here you have a quick and dirty patch. TRAILS-81.v20070711.patch
I think reflection is not needed now, but you tell me. If this works I will move this the decoration to a DescriptorAnnotationHandler whenever I have a chance. The issue of inverse is worrisome...
My version supported it in order for the ognl to operate properly. Since yours does not support that... I am wondering if everything works as originally did with my version. I will run thru it for all cases when I come up with something workable. Sorry I went heavy on this jira... just wanted to get the attention it needed. I will check out your patch today and let you know results. Appreciate the help STATUS...
I had dropped the ball on this since it's creation. The past 4 weeks have been hampered with ognl breakages and running the trails app has been close to impossible. Couple that with pre-emptions and there is not alot I have been able to reliably do with regard to operating this functionality (that being the OneToOne editor). I would like to resume and fix this unless someone has a better in to the code than I do. This bug basically requires that the OneToOne editor be re-looked-at and resolved since it was breaking after the tapestry-4.1.2 merge. Ok, the new behavior of this editor currently is the following asof current checkins:
Click NEW on the OneToOne property (ie. and nothing happens.
Needed to clarify the title to this...
Although soft associations by AssociationSelect may have been mentioned, impacted and subsequently resolved throughout the framework, the main initiative behind this JIRA was the impact to hard associations implemented by the OneToOne property editor. They got broken post T-4.1 merge. The semantics surrounding the descriptor decorator are under review. The main problem is that the case logic currently is resulting in the wrong desciptor being allocated at bootstrap. This could use some hands on testing...
If you see anything just give me a holler. BTW:
Originally I designed this to operate the @OneToOne attribute mappedBy which gave us a handle to the inverse that the developer codes to the class. This design has changed and I decided to go with the extra annotation @HardOneToOne for detection/isolation of logic. I would have preferred to instrument @OneToOne with Identity but was discouraged from that. For your pojos... Here is the use model... OWNER- We will use what roster demo uses to explain... Organization-- This says only one director can be anchored to any Organization. Here is the usage... Organization.JAVA Director.JAVA |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||