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 [email protected], "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: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of simonjpalmer > Sent: Friday, February 23, 2007 2:47 AM > To: [email protected] > 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=60&c > 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 [email protected] <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 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] > <mailto:flexcoders%40yahoogroups.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] > <mailto:flexcoders%40yahoogroups.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] > <mailto:flexcoders%40yahoogroups.com> > > [mailto:[email protected] > <mailto:flexcoders%40yahoogroups.com> ] On > > > > Behalf Of parkerwhirlow > > > > Sent: Thursday, February 15, 2007 3:29 PM > > > > To: [email protected] > <mailto: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 [email protected] > <mailto:flexcoders%40yahoogroups.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: [email protected] > <mailto:flexcoders%40yahoogroups.com> > > <mailto:flexcoders%40yahoogroups.com> > > > > [mailto:[email protected] > <mailto:flexcoders%40yahoogroups.com> > > <mailto:flexcoders%40yahoogroups.com> > > > > ] On > > > > > Behalf Of parkerwhirlow > > > > > Sent: Thursday, February 01, 2007 6:05 PM > > > > > To: [email protected] > <mailto:flexcoders%40yahoogroups.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> > > > > > > <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 > > > > > > > > > > > > > > >
