Re: [flexcoders] Re: FDS/Hibernate Sample of updating hierarchical list of values
and have it work in FDS2. It will be in an upcoming public beta but I don't think we've announced the dates on that. Jeff From: flexcoders@yahoogroups.com flexcoders%40yahoogroups.com [mailto:flexcoders@yahoogroups.com flexcoders%40yahoogroups.com] On Behalf Of parkerwhirlow Sent: Thursday, February 15, 2007 3:29 PM To: flexcoders@yahoogroups.com flexcoders%40yahoogroups.com Subject: [flexcoders] Re: FDS/Hibernate Sample of updating hierarchical list of values Hey Jeff, just curious if you've got any updated HibernateAssembler code with some fixes? Any idea when this would be available? thanks, PW --- In flexcoders@yahoogroups.com flexcoders%40yahoogroups.com mailto:flexcoders% flexcoders%2540yahoogroups.com , Jeff Vroom jvroom@ wrote: My apologies - this does look like a bug. I need to do more testing on this case myself, but I think one of the big problems here is that we are trying to do conflict detection on our own in the hibernate assembler's updateItem method. Unless you are using a strict isolation level in your DB (repeatable read or serializable) this is not going to be transactionally correct anyway since the DB version can be modified after we have executed the query and before we do our update. We probably should not be getting the server version at all... hibernate has its own optimistic concurrency support that we should be using if it is enabled. That is probably the only way to get atomic conflict detection without resorting to using those particularly slow isolation levels. That would potentially get rid of the conflicting version of the item in the transaction. The other thing I need to look into is the merge method in hibernate. Seems like we should probably be using that in the updateItem method? I'll be working on this next week so will send out any updates I can to the code. Jeff From: flexcoders@yahoogroups.com flexcoders%40yahoogroups.com mailto:flexcoders% flexcoders%2540yahoogroups.com [mailto:flexcoders@yahoogroups.com flexcoders%40yahoogroups.com mailto:flexcoders% flexcoders%2540yahoogroups.com ] On Behalf Of parkerwhirlow Sent: Thursday, February 01, 2007 6:05 PM To: flexcoders@yahoogroups.com flexcoders%40yahoogroups.com mailto:flexcoders% flexcoders%2540yahoogroups.com Subject: [flexcoders] FDS/Hibernate Sample of updating hierarchical list of values Hi all, I have been tearing my hair out trying to get FDS/Hibernate to update a hierarchical list of values. Even the simplest of collection mappings in Hibernate cause various exceptions when trying to update. Before I post my details, does anyone have any examples of this that work? Has anyone ever even gotten this to work? I have two objects mapped in Hibernate: - Family Person where a Family has a Set of Person familyMembers. My FDS destination is to Family, and I am trying to update a family member (just the name) through this destination. First, I was getting Hibernate NonUniqueObjectException, which I finally tracked down to having my hibernate collection mapping set to lazy=false This caused all of the family member Person objects to be loaded into the PersistenceContext when the HibernateAssembler loaded the serverVersion of the Family. Then, once I set lazy=true on the collection mapping, I was getting an exception that A collection with cascade=all-delete-orphan was no longer referenced by the owning entity instance... since it is assigning a whole new collection to the familyMembers property one becomes unreferenced, and the other referenced. Sooo I can't use delete orphan to delete the family members when the family is deleted... OK. So then I make cascade=all. Now I'm getting ORA-01407: cannot update (SCHEMA.T_PERSON.FAMILYID) to NULL... I'm guessing that it's processing the dereferenced collection first (trying to detatch any Person's from the family before they're re-attached by the new collection. I can't believe this is so difficult... For more info on my setup and test case, please see my original post: http://tech.groups.yahoo.com/group/flexcoders/message/63308 http://tech.groups.yahoo.com/group/flexcoders/message/63308 http://tech.groups.yahoo.com/group/flexcoders/message/63308 http://tech.groups.yahoo.com/group/flexcoders/message/63308 any comments as to if anyone has done this successfully are greatly appreciated! thanks, PW
Re: [flexcoders] Re: FDS/Hibernate Sample of updating hierarchical list of values
That's an excellent message and I had ran through same issues myself and feel your pain... Regards, Valy - Original Message From: simonjpalmer [EMAIL PROTECTED] To: flexcoders@yahoogroups.com Sent: Friday, February 23, 2007 5:34:38 AM Subject: [flexcoders] Re: FDS/Hibernate Sample of updating hierarchical list of values PW and Jeff, PW, you and I seem to be in the same boat. I am trying to fight off the people who were flex skeptics to start with. Not being able to write data back makes the whole thing look pretty amateur and confirms people's belief that the technology isn't ready - which given this experience it clearly isn't. The baby is definitely at risk of being thrown out with the bath water. It stands in our company simply because I have the final call as Technical Director (CTO if you are in the US). I am a huge flex advocate and really doing my best to evangelise on the topic. What's more I think that the bridge to operational data is the most profound leap forward for flash, it takes it out of the world of gimicks and into the world of real business applications. Jeff, you and your and team deserve huge credit for that vision and excellent execution. However, much as it pains me to say it, the bottom line is that the hibernate middle tier provided does not work, as PW and I (and a host of other people on various forums) have found. I know that I can re-write the whole thing myself and will probably have to, but when introducing new technologies it is unfortunately all about initial perception. I have made a career of doing this sort of thing myself and I have seen excellent projects fail to fly because of low initial quality, even though we fixed them immediately, the damage was done because people's impression was that they were flaky. I'm sure you know it is hard to get back from that first impression and the word of mouth that springs from it. Once it becomes entrenched that opinion becomes fact and you are irrevocably lost. If I were Adobe I would be a little worried about the tone of the posts I am seeing about integration with Hibernate. The Hibernate Assembler is very important and I would really hate to see that happen to it. The corollary is very unfortunate. That little bit of technology transform the boardroom conversation about FDS. Suddenly the cost of the licensing of FDS becomes justifiable against the dev cost savings because we can just plug into the ORM. Having made that justification myself it is very difficult for me now to go back and say, by the way I also have to incur the dev costs. When asked why? I have to confess that the Adobe code doesn't work and we don't know when we're getting a fix. For the Flex/Flash skeptics in the room that's a god send. For me it is a complete nightmare. It is hard for me to separate the cost of FDS licenses (which is almost prohibitively large) against the cost of dev. I would urge Jeff and Co to get the Hibernate Assembler code watertight and shipping asap. If I can be of any assistance I will gladly offer my services. If either of you would like to contact me, post a reply and I will happily give you my details. Simon Palmer Technical Director The PMCo 62 St Peters Street St Albans HERTS AL1 3HG UK --- In [EMAIL PROTECTED] ups.com, parkerwhirlow parkerwhirlow@ ... wrote: Thats very unfortunate. I'm getting farther and farther into hot water not being able to reliably update our data model using Flex. Last it was just wait for 2.0.1, there's a lot of Hibernate/FDS fixes in it and now we're waiting for another unknown amount of time for fixes we can only hope will help our situation. I'm apologize, I understand it's not your fault, and I really appreciate the insight you provide as to what can be causing our problems, I'm just getting up to my neck in unsolved problems. If you have any insight as to roughly when this next release could occur, can you tip me off? thanks, PW --- In [EMAIL PROTECTED] ups.com, Jeff Vroom jvroom@ wrote: I have finished making the changes and the use of the merge call seems to be a) much simpler and b) more robust than the way the current code works. Unfortunately we've made enough changes to the code surrounding the HibernateAssembler so I can't just send you the updated file and have it work in FDS2. It will be in an upcoming public beta but I don't think we've announced the dates on that. Jeff _ _ __ From: [EMAIL PROTECTED] ups.com [mailto:[EMAIL PROTECTED] ups.com] On Behalf Of parkerwhirlow Sent: Thursday, February 15, 2007 3:29 PM To: [EMAIL PROTECTED] ups.com Subject: [flexcoders] Re: FDS/Hibernate Sample of updating hierarchical list of values Hey Jeff, just curious if you've got
[flexcoders] Re: FDS/Hibernate Sample of updating hierarchical list of values
Jeff, thanks very much for taking the time to reply, I appreciate it. I would be very happy to be engaged in the beta process. Can you give me some indication of what I might have to do in order to add my name to the list of beta sites? Is it possible for you to give a rough date when we might expect the beta to start (to which you will not be held)? The reason I ask is that I have a pressing and immediate need to have this addressed and about to undertake an initiative to replace the Hibernate Assembler (probably a Spring/Hibernate Java Assembler of some kind). If the beta is soon I may hold off and put attention elsewhere. Any insight you could give would be greatly appreciated. Kind regards Simon Palmer --- In flexcoders@yahoogroups.com, Jeff Vroom [EMAIL PROTECTED] wrote: My apologies for the Hibernate problems y'all have been having. We do have a bunch of users happily using this for relatively simple use cases but as your domain models grow in complexity, you may run into some problems. Here are the set of problems I currently know about. 1) unique object exceptions during updateItem. The one case where I know this will happen is if you have hibernate associations which do not have corresponding FDS associations (i.e. the hierarchical values). This should be supported and it turns out that the fix for the problem is to use hibernate's merge method instead of trying to do the merge by hand as is done in 2.0.1's updateItem method. The code in updateItem that is causing the bulk of this problem is the code which fetches the current server version to do conflict detection. In doing that, it creates hibernate instances in the session which may conflict with instances that get sent in by the client. Hibernate's merge method takes care of all of this for us. 2) Domain objects need id/equals test which is based on the id. Some of the code in the hibernate assembler is using the equals method when it should be comparing the id properties. You can workaround this by having equals and hashCode methods which are based on the id. 3) Session closed errors trying to fetch associations when we are writing objects to the client. I'm not sure why the current fetchObjectProperties method is not fetching these objects for some people's domain model but if anyone has a test case which can reproduce this I'm interested. It should be walking down all public properties and fetching them - the same way that our serialization code is working but somehow I must be missing something in the traversal code. There is a public beta coming out fairly soon which will have 1) and 2) fixed. I haven't had a chance to backport these fixes to a version of the hibernate assembler which works in 2.0.1 but if there is enough demand (and I can find enough time!) I could probably do that. Of course I'd rather get anyone running into trouble on the beta so we can make sure that version is solid. Jeff From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of simonjpalmer Sent: Friday, February 23, 2007 2:47 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: FDS/Hibernate Sample of updating hierarchical list of values PW, BTW pop over to the FDS forum at Adobe http://www.adobe.com/cfusion/webforums/forum/categories.cfm?forumid=60c atid=583 http://www.adobe.com/cfusion/webforums/forum/categories.cfm?forumid=60; catid=583 take a look at the thread called Parent Child Hierarchy with FDS and Hibernate SP --- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com , simonjpalmer simonjpalmer@ wrote: PW and Jeff, PW, you and I seem to be in the same boat. I am trying to fight off the people who were flex skeptics to start with. Not being able to write data back makes the whole thing look pretty amateur and confirms people's belief that the technology isn't ready - which given this experience it clearly isn't. The baby is definitely at risk of being thrown out with the bath water. It stands in our company simply because I have the final call as Technical Director (CTO if you are in the US). I am a huge flex advocate and really doing my best to evangelise on the topic. What's more I think that the bridge to operational data is the most profound leap forward for flash, it takes it out of the world of gimicks and into the world of real business applications. Jeff, you and your and team deserve huge credit for that vision and excellent execution. However, much as it pains me to say it, the bottom line is that the hibernate middle tier provided does not work, as PW and I (and a host of other people on various forums) have found. I know that I can re-write the whole thing myself and will probably have to, but when introducing new technologies it is unfortunately all about
[flexcoders] Re: FDS/Hibernate Sample of updating hierarchical list of values
PW and Jeff, PW, you and I seem to be in the same boat. I am trying to fight off the people who were flex skeptics to start with. Not being able to write data back makes the whole thing look pretty amateur and confirms people's belief that the technology isn't ready - which given this experience it clearly isn't. The baby is definitely at risk of being thrown out with the bath water. It stands in our company simply because I have the final call as Technical Director (CTO if you are in the US). I am a huge flex advocate and really doing my best to evangelise on the topic. What's more I think that the bridge to operational data is the most profound leap forward for flash, it takes it out of the world of gimicks and into the world of real business applications. Jeff, you and your and team deserve huge credit for that vision and excellent execution. However, much as it pains me to say it, the bottom line is that the hibernate middle tier provided does not work, as PW and I (and a host of other people on various forums) have found. I know that I can re-write the whole thing myself and will probably have to, but when introducing new technologies it is unfortunately all about initial perception. I have made a career of doing this sort of thing myself and I have seen excellent projects fail to fly because of low initial quality, even though we fixed them immediately, the damage was done because people's impression was that they were flaky. I'm sure you know it is hard to get back from that first impression and the word of mouth that springs from it. Once it becomes entrenched that opinion becomes fact and you are irrevocably lost. If I were Adobe I would be a little worried about the tone of the posts I am seeing about integration with Hibernate. The Hibernate Assembler is very important and I would really hate to see that happen to it. The corollary is very unfortunate. That little bit of technology transform the boardroom conversation about FDS. Suddenly the cost of the licensing of FDS becomes justifiable against the dev cost savings because we can just plug into the ORM. Having made that justification myself it is very difficult for me now to go back and say, by the way I also have to incur the dev costs. When asked why? I have to confess that the Adobe code doesn't work and we don't know when we're getting a fix. For the Flex/Flash skeptics in the room that's a god send. For me it is a complete nightmare. It is hard for me to separate the cost of FDS licenses (which is almost prohibitively large) against the cost of dev. I would urge Jeff and Co to get the Hibernate Assembler code watertight and shipping asap. If I can be of any assistance I will gladly offer my services. If either of you would like to contact me, post a reply and I will happily give you my details. Simon Palmer Technical Director The PMCo 62 St Peters Street St Albans HERTS AL1 3HG UK --- In flexcoders@yahoogroups.com, parkerwhirlow [EMAIL PROTECTED] wrote: Thats very unfortunate. I'm getting farther and farther into hot water not being able to reliably update our data model using Flex. Last it was just wait for 2.0.1, there's a lot of Hibernate/FDS fixes in it and now we're waiting for another unknown amount of time for fixes we can only hope will help our situation. I'm apologize, I understand it's not your fault, and I really appreciate the insight you provide as to what can be causing our problems, I'm just getting up to my neck in unsolved problems. If you have any insight as to roughly when this next release could occur, can you tip me off? thanks, PW --- In flexcoders@yahoogroups.com, Jeff Vroom jvroom@ wrote: I have finished making the changes and the use of the merge call seems to be a) much simpler and b) more robust than the way the current code works. Unfortunately we've made enough changes to the code surrounding the HibernateAssembler so I can't just send you the updated file and have it work in FDS2. It will be in an upcoming public beta but I don't think we've announced the dates on that. Jeff From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of parkerwhirlow Sent: Thursday, February 15, 2007 3:29 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: FDS/Hibernate Sample of updating hierarchical list of values Hey Jeff, just curious if you've got any updated HibernateAssembler code with some fixes? Any idea when this would be available? thanks, PW --- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com , Jeff Vroom jvroom@ wrote: My apologies - this does look like a bug. I need to do more testing on this case myself, but I think one of the big problems here is that we are trying to do conflict detection on our own in the hibernate assembler's updateItem method. Unless you are using
[flexcoders] Re: FDS/Hibernate Sample of updating hierarchical list of values
PW, BTW pop over to the FDS forum at Adobe http://www.adobe.com/cfusion/webforums/forum/categories.cfm?forumid=60catid=583 take a look at the thread called Parent Child Hierarchy with FDS and Hibernate SP --- In flexcoders@yahoogroups.com, simonjpalmer [EMAIL PROTECTED] wrote: PW and Jeff, PW, you and I seem to be in the same boat. I am trying to fight off the people who were flex skeptics to start with. Not being able to write data back makes the whole thing look pretty amateur and confirms people's belief that the technology isn't ready - which given this experience it clearly isn't. The baby is definitely at risk of being thrown out with the bath water. It stands in our company simply because I have the final call as Technical Director (CTO if you are in the US). I am a huge flex advocate and really doing my best to evangelise on the topic. What's more I think that the bridge to operational data is the most profound leap forward for flash, it takes it out of the world of gimicks and into the world of real business applications. Jeff, you and your and team deserve huge credit for that vision and excellent execution. However, much as it pains me to say it, the bottom line is that the hibernate middle tier provided does not work, as PW and I (and a host of other people on various forums) have found. I know that I can re-write the whole thing myself and will probably have to, but when introducing new technologies it is unfortunately all about initial perception. I have made a career of doing this sort of thing myself and I have seen excellent projects fail to fly because of low initial quality, even though we fixed them immediately, the damage was done because people's impression was that they were flaky. I'm sure you know it is hard to get back from that first impression and the word of mouth that springs from it. Once it becomes entrenched that opinion becomes fact and you are irrevocably lost. If I were Adobe I would be a little worried about the tone of the posts I am seeing about integration with Hibernate. The Hibernate Assembler is very important and I would really hate to see that happen to it. The corollary is very unfortunate. That little bit of technology transform the boardroom conversation about FDS. Suddenly the cost of the licensing of FDS becomes justifiable against the dev cost savings because we can just plug into the ORM. Having made that justification myself it is very difficult for me now to go back and say, by the way I also have to incur the dev costs. When asked why? I have to confess that the Adobe code doesn't work and we don't know when we're getting a fix. For the Flex/Flash skeptics in the room that's a god send. For me it is a complete nightmare. It is hard for me to separate the cost of FDS licenses (which is almost prohibitively large) against the cost of dev. I would urge Jeff and Co to get the Hibernate Assembler code watertight and shipping asap. If I can be of any assistance I will gladly offer my services. If either of you would like to contact me, post a reply and I will happily give you my details. Simon Palmer Technical Director The PMCo 62 St Peters Street St Albans HERTS AL1 3HG UK --- In flexcoders@yahoogroups.com, parkerwhirlow parkerwhirlow@ wrote: Thats very unfortunate. I'm getting farther and farther into hot water not being able to reliably update our data model using Flex. Last it was just wait for 2.0.1, there's a lot of Hibernate/FDS fixes in it and now we're waiting for another unknown amount of time for fixes we can only hope will help our situation. I'm apologize, I understand it's not your fault, and I really appreciate the insight you provide as to what can be causing our problems, I'm just getting up to my neck in unsolved problems. If you have any insight as to roughly when this next release could occur, can you tip me off? thanks, PW --- In flexcoders@yahoogroups.com, Jeff Vroom jvroom@ wrote: I have finished making the changes and the use of the merge call seems to be a) much simpler and b) more robust than the way the current code works. Unfortunately we've made enough changes to the code surrounding the HibernateAssembler so I can't just send you the updated file and have it work in FDS2. It will be in an upcoming public beta but I don't think we've announced the dates on that. Jeff From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of parkerwhirlow Sent: Thursday, February 15, 2007 3:29 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: FDS/Hibernate Sample of updating hierarchical list of values Hey Jeff, just curious if you've got any updated HibernateAssembler code with some fixes? Any idea when this would
RE: [flexcoders] Re: FDS/Hibernate Sample of updating hierarchical list of values
My apologies for the Hibernate problems y'all have been having. We do have a bunch of users happily using this for relatively simple use cases but as your domain models grow in complexity, you may run into some problems. Here are the set of problems I currently know about. 1) unique object exceptions during updateItem. The one case where I know this will happen is if you have hibernate associations which do not have corresponding FDS associations (i.e. the hierarchical values). This should be supported and it turns out that the fix for the problem is to use hibernate's merge method instead of trying to do the merge by hand as is done in 2.0.1's updateItem method. The code in updateItem that is causing the bulk of this problem is the code which fetches the current server version to do conflict detection. In doing that, it creates hibernate instances in the session which may conflict with instances that get sent in by the client. Hibernate's merge method takes care of all of this for us. 2) Domain objects need id/equals test which is based on the id. Some of the code in the hibernate assembler is using the equals method when it should be comparing the id properties. You can workaround this by having equals and hashCode methods which are based on the id. 3) Session closed errors trying to fetch associations when we are writing objects to the client. I'm not sure why the current fetchObjectProperties method is not fetching these objects for some people's domain model but if anyone has a test case which can reproduce this I'm interested. It should be walking down all public properties and fetching them - the same way that our serialization code is working but somehow I must be missing something in the traversal code. There is a public beta coming out fairly soon which will have 1) and 2) fixed. I haven't had a chance to backport these fixes to a version of the hibernate assembler which works in 2.0.1 but if there is enough demand (and I can find enough time!) I could probably do that. Of course I'd rather get anyone running into trouble on the beta so we can make sure that version is solid. Jeff From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of simonjpalmer Sent: Friday, February 23, 2007 2:47 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: FDS/Hibernate Sample of updating hierarchical list of values PW, BTW pop over to the FDS forum at Adobe http://www.adobe.com/cfusion/webforums/forum/categories.cfm?forumid=60c atid=583 http://www.adobe.com/cfusion/webforums/forum/categories.cfm?forumid=60; catid=583 take a look at the thread called Parent Child Hierarchy with FDS and Hibernate SP --- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com , simonjpalmer [EMAIL PROTECTED] wrote: PW and Jeff, PW, you and I seem to be in the same boat. I am trying to fight off the people who were flex skeptics to start with. Not being able to write data back makes the whole thing look pretty amateur and confirms people's belief that the technology isn't ready - which given this experience it clearly isn't. The baby is definitely at risk of being thrown out with the bath water. It stands in our company simply because I have the final call as Technical Director (CTO if you are in the US). I am a huge flex advocate and really doing my best to evangelise on the topic. What's more I think that the bridge to operational data is the most profound leap forward for flash, it takes it out of the world of gimicks and into the world of real business applications. Jeff, you and your and team deserve huge credit for that vision and excellent execution. However, much as it pains me to say it, the bottom line is that the hibernate middle tier provided does not work, as PW and I (and a host of other people on various forums) have found. I know that I can re-write the whole thing myself and will probably have to, but when introducing new technologies it is unfortunately all about initial perception. I have made a career of doing this sort of thing myself and I have seen excellent projects fail to fly because of low initial quality, even though we fixed them immediately, the damage was done because people's impression was that they were flaky. I'm sure you know it is hard to get back from that first impression and the word of mouth that springs from it. Once it becomes entrenched that opinion becomes fact and you are irrevocably lost. If I were Adobe I would be a little worried about the tone of the posts I am seeing about integration with Hibernate. The Hibernate Assembler is very important and I would really hate to see that happen to it. The corollary is very unfortunate. That little bit of technology transform the boardroom conversation about FDS. Suddenly the cost of the licensing of FDS becomes justifiable against the dev cost savings because we
[flexcoders] Re: FDS/Hibernate Sample of updating hierarchical list of values
Thats very unfortunate. I'm getting farther and farther into hot water not being able to reliably update our data model using Flex. Last it was just wait for 2.0.1, there's a lot of Hibernate/FDS fixes in it and now we're waiting for another unknown amount of time for fixes we can only hope will help our situation. I'm apologize, I understand it's not your fault, and I really appreciate the insight you provide as to what can be causing our problems, I'm just getting up to my neck in unsolved problems. If you have any insight as to roughly when this next release could occur, can you tip me off? thanks, PW --- In flexcoders@yahoogroups.com, Jeff Vroom [EMAIL PROTECTED] wrote: I have finished making the changes and the use of the merge call seems to be a) much simpler and b) more robust than the way the current code works. Unfortunately we've made enough changes to the code surrounding the HibernateAssembler so I can't just send you the updated file and have it work in FDS2. It will be in an upcoming public beta but I don't think we've announced the dates on that. Jeff From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of parkerwhirlow Sent: Thursday, February 15, 2007 3:29 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: FDS/Hibernate Sample of updating hierarchical list of values Hey Jeff, just curious if you've got any updated HibernateAssembler code with some fixes? Any idea when this would be available? thanks, PW --- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com , Jeff Vroom jvroom@ wrote: My apologies - this does look like a bug. I need to do more testing on this case myself, but I think one of the big problems here is that we are trying to do conflict detection on our own in the hibernate assembler's updateItem method. Unless you are using a strict isolation level in your DB (repeatable read or serializable) this is not going to be transactionally correct anyway since the DB version can be modified after we have executed the query and before we do our update. We probably should not be getting the server version at all... hibernate has its own optimistic concurrency support that we should be using if it is enabled. That is probably the only way to get atomic conflict detection without resorting to using those particularly slow isolation levels. That would potentially get rid of the conflicting version of the item in the transaction. The other thing I need to look into is the merge method in hibernate. Seems like we should probably be using that in the updateItem method? I'll be working on this next week so will send out any updates I can to the code. Jeff From: flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com [mailto:flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com ] On Behalf Of parkerwhirlow Sent: Thursday, February 01, 2007 6:05 PM To: flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com Subject: [flexcoders] FDS/Hibernate Sample of updating hierarchical list of values Hi all, I have been tearing my hair out trying to get FDS/Hibernate to update a hierarchical list of values. Even the simplest of collection mappings in Hibernate cause various exceptions when trying to update. Before I post my details, does anyone have any examples of this that work? Has anyone ever even gotten this to work? I have two objects mapped in Hibernate: - Family Person where a Family has a Set of Person familyMembers. My FDS destination is to Family, and I am trying to update a family member (just the name) through this destination. First, I was getting Hibernate NonUniqueObjectException, which I finally tracked down to having my hibernate collection mapping set to lazy=false This caused all of the family member Person objects to be loaded into the PersistenceContext when the HibernateAssembler loaded the serverVersion of the Family. Then, once I set lazy=true on the collection mapping, I was getting an exception that A collection with cascade=all-delete-orphan was no longer referenced by the owning entity instance... since it is assigning a whole new collection to the familyMembers property one becomes unreferenced, and the other referenced. Sooo I can't use delete orphan to delete the family members when the family is deleted... OK. So then I make cascade=all. Now I'm getting ORA-01407: cannot update (SCHEMA.T_PERSON.FAMILYID) to NULL... I'm guessing that it's processing the dereferenced collection first (trying to detatch any Person's from the family before they're re-attached by the new collection. I can't believe this is so difficult... For more info on my setup and test case, please see my original post
[flexcoders] Re: FDS/Hibernate Sample of updating hierarchical list of values
Hey Jeff, just curious if you've got any updated HibernateAssembler code with some fixes? Any idea when this would be available? thanks, PW --- In flexcoders@yahoogroups.com, Jeff Vroom [EMAIL PROTECTED] wrote: My apologies - this does look like a bug. I need to do more testing on this case myself, but I think one of the big problems here is that we are trying to do conflict detection on our own in the hibernate assembler's updateItem method. Unless you are using a strict isolation level in your DB (repeatable read or serializable) this is not going to be transactionally correct anyway since the DB version can be modified after we have executed the query and before we do our update. We probably should not be getting the server version at all... hibernate has its own optimistic concurrency support that we should be using if it is enabled. That is probably the only way to get atomic conflict detection without resorting to using those particularly slow isolation levels. That would potentially get rid of the conflicting version of the item in the transaction. The other thing I need to look into is the merge method in hibernate. Seems like we should probably be using that in the updateItem method? I'll be working on this next week so will send out any updates I can to the code. Jeff From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of parkerwhirlow Sent: Thursday, February 01, 2007 6:05 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] FDS/Hibernate Sample of updating hierarchical list of values Hi all, I have been tearing my hair out trying to get FDS/Hibernate to update a hierarchical list of values. Even the simplest of collection mappings in Hibernate cause various exceptions when trying to update. Before I post my details, does anyone have any examples of this that work? Has anyone ever even gotten this to work? I have two objects mapped in Hibernate: - Family Person where a Family has a Set of Person familyMembers. My FDS destination is to Family, and I am trying to update a family member (just the name) through this destination. First, I was getting Hibernate NonUniqueObjectException, which I finally tracked down to having my hibernate collection mapping set to lazy=false This caused all of the family member Person objects to be loaded into the PersistenceContext when the HibernateAssembler loaded the serverVersion of the Family. Then, once I set lazy=true on the collection mapping, I was getting an exception that A collection with cascade=all-delete-orphan was no longer referenced by the owning entity instance... since it is assigning a whole new collection to the familyMembers property one becomes unreferenced, and the other referenced. Sooo I can't use delete orphan to delete the family members when the family is deleted... OK. So then I make cascade=all. Now I'm getting ORA-01407: cannot update (SCHEMA.T_PERSON.FAMILYID) to NULL... I'm guessing that it's processing the dereferenced collection first (trying to detatch any Person's from the family before they're re-attached by the new collection. I can't believe this is so difficult... For more info on my setup and test case, please see my original post: http://tech.groups.yahoo.com/group/flexcoders/message/63308 http://tech.groups.yahoo.com/group/flexcoders/message/63308 any comments as to if anyone has done this successfully are greatly appreciated! thanks, PW
RE: [flexcoders] Re: FDS/Hibernate Sample of updating hierarchical list of values
I have finished making the changes and the use of the merge call seems to be a) much simpler and b) more robust than the way the current code works. Unfortunately we've made enough changes to the code surrounding the HibernateAssembler so I can't just send you the updated file and have it work in FDS2. It will be in an upcoming public beta but I don't think we've announced the dates on that. Jeff From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of parkerwhirlow Sent: Thursday, February 15, 2007 3:29 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: FDS/Hibernate Sample of updating hierarchical list of values Hey Jeff, just curious if you've got any updated HibernateAssembler code with some fixes? Any idea when this would be available? thanks, PW --- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com , Jeff Vroom [EMAIL PROTECTED] wrote: My apologies - this does look like a bug. I need to do more testing on this case myself, but I think one of the big problems here is that we are trying to do conflict detection on our own in the hibernate assembler's updateItem method. Unless you are using a strict isolation level in your DB (repeatable read or serializable) this is not going to be transactionally correct anyway since the DB version can be modified after we have executed the query and before we do our update. We probably should not be getting the server version at all... hibernate has its own optimistic concurrency support that we should be using if it is enabled. That is probably the only way to get atomic conflict detection without resorting to using those particularly slow isolation levels. That would potentially get rid of the conflicting version of the item in the transaction. The other thing I need to look into is the merge method in hibernate. Seems like we should probably be using that in the updateItem method? I'll be working on this next week so will send out any updates I can to the code. Jeff From: flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com [mailto:flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com ] On Behalf Of parkerwhirlow Sent: Thursday, February 01, 2007 6:05 PM To: flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com Subject: [flexcoders] FDS/Hibernate Sample of updating hierarchical list of values Hi all, I have been tearing my hair out trying to get FDS/Hibernate to update a hierarchical list of values. Even the simplest of collection mappings in Hibernate cause various exceptions when trying to update. Before I post my details, does anyone have any examples of this that work? Has anyone ever even gotten this to work? I have two objects mapped in Hibernate: - Family Person where a Family has a Set of Person familyMembers. My FDS destination is to Family, and I am trying to update a family member (just the name) through this destination. First, I was getting Hibernate NonUniqueObjectException, which I finally tracked down to having my hibernate collection mapping set to lazy=false This caused all of the family member Person objects to be loaded into the PersistenceContext when the HibernateAssembler loaded the serverVersion of the Family. Then, once I set lazy=true on the collection mapping, I was getting an exception that A collection with cascade=all-delete-orphan was no longer referenced by the owning entity instance... since it is assigning a whole new collection to the familyMembers property one becomes unreferenced, and the other referenced. Sooo I can't use delete orphan to delete the family members when the family is deleted... OK. So then I make cascade=all. Now I'm getting ORA-01407: cannot update (SCHEMA.T_PERSON.FAMILYID) to NULL... I'm guessing that it's processing the dereferenced collection first (trying to detatch any Person's from the family before they're re-attached by the new collection. I can't believe this is so difficult... For more info on my setup and test case, please see my original post: http://tech.groups.yahoo.com/group/flexcoders/message/63308 http://tech.groups.yahoo.com/group/flexcoders/message/63308 http://tech.groups.yahoo.com/group/flexcoders/message/63308 http://tech.groups.yahoo.com/group/flexcoders/message/63308 any comments as to if anyone has done this successfully are greatly appreciated! thanks, PW
RE: [flexcoders] Re: FDS/Hibernate Sample of updating hierarchical list of values
Yeah, I picked up that change last week. Sorry we did not find it in
time for 2.0.1 (it was frozen by the time I saw your bug). Thanks for
catching that problem.
Jeff
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of parkerwhirlow
Sent: Friday, February 02, 2007 8:26 PM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Re: FDS/Hibernate Sample of updating hierarchical
list of values
Jeff, thanks for looking into this...
while you're at it, I posted this as a bug to the wishlist site, but
it didn't make it into 2.0.1... I've taken to building the
HibernateAssembler myself to try to get things working, but this is
dedfinitely a defect:
HibernateAssembler.java (fds2.0.1 release version)
Line (starting): 691
int k;
for (k = i; k toList.size(); k++)
{
if (assocType.getIdentityFromItem(toList.get(i)).equals(fromId))
break;
}
Notice that the index used in the loop is (i) not (k)... this was
causing some really odd behavior that took me a good while to figure
out =)
thanks again,
PW
--- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com
, Jeff Vroom [EMAIL PROTECTED] wrote:
My apologies - this does look like a bug. I need to do more testing on
this case myself, but I think one of the big problems here is that we
are trying to do conflict detection on our own in the hibernate
assembler's updateItem method. Unless you are using a strict isolation
level in your DB (repeatable read or serializable) this is not going
to
be transactionally correct anyway since the DB version can be modified
after we have executed the query and before we do our update. We
probably should not be getting the server version at all... hibernate
has its own optimistic concurrency support that we should be using if
it
is enabled. That is probably the only way to get atomic conflict
detection without resorting to using those particularly slow isolation
levels.
That would potentially get rid of the conflicting version of the item
in
the transaction. The other thing I need to look into is the merge
method in hibernate. Seems like we should probably be using that in
the
updateItem method? I'll be working on this next week so will send out
any updates I can to the code.
Jeff
[flexcoders] Re: FDS/Hibernate Sample of updating hierarchical list of values
Jeff, thanks for looking into this...
while you're at it, I posted this as a bug to the wishlist site, but
it didn't make it into 2.0.1... I've taken to building the
HibernateAssembler myself to try to get things working, but this is
dedfinitely a defect:
HibernateAssembler.java (fds2.0.1 release version)
Line (starting): 691
int k;
for (k = i; k toList.size(); k++)
{
if (assocType.getIdentityFromItem(toList.get(i)).equals(fromId))
break;
}
Notice that the index used in the loop is (i) not (k)... this was
causing some really odd behavior that took me a good while to figure
out =)
thanks again,
PW
--- In flexcoders@yahoogroups.com, Jeff Vroom [EMAIL PROTECTED] wrote:
My apologies - this does look like a bug. I need to do more testing on
this case myself, but I think one of the big problems here is that we
are trying to do conflict detection on our own in the hibernate
assembler's updateItem method. Unless you are using a strict isolation
level in your DB (repeatable read or serializable) this is not going to
be transactionally correct anyway since the DB version can be modified
after we have executed the query and before we do our update. We
probably should not be getting the server version at all... hibernate
has its own optimistic concurrency support that we should be using if it
is enabled. That is probably the only way to get atomic conflict
detection without resorting to using those particularly slow isolation
levels.
That would potentially get rid of the conflicting version of the item in
the transaction. The other thing I need to look into is the merge
method in hibernate. Seems like we should probably be using that in the
updateItem method? I'll be working on this next week so will send out
any updates I can to the code.
Jeff
