We are still dealing with this problem on a daily basis on my current project, and there still doesn't seem to be a good answer, at least as far as BlazeDS goes. The way that web frameworks deal with the issue is lazy loading, so that the data access to load the child objects doesn't happen until you actually access those objects, but because we're serializing the objects when we send them acrossed the wire in BlazeDS, the entire object graph gets realized, leading to some HUGE amounts of data possible, depending on how complex your data is. Now supposedly they have "fixed" this, meaning enabled lazy loading, in GraniteDS, and many are hoping for a similar solution coming out of the Spring/BlazeDS integration project. I say supposedly because I haven't personally tested it, we're 7 months into an 8 month project, not a good time to be thinking about changing out such a major part of our project! Good luck! Mike
--- In flexcoders@yahoogroups.com, "max.bruchmann" > So now everytime we send a person object back to the blazeds/hibernate > backend all the groups he belongs to are getting serialized as well. > This means a lot of overhead gets send to backend when I only modify > some primitve data like the name. > > Even more problematic would be if in addition the group objects > themselves would have list of persons that belongs to them. > > I guess I could use the [Transient] Metatag to not send the collection > fields, but then I could not modify the groups in a person object easily. > > So if there is any best practice for these kind of problems, please > let me know. > > Thanks in advance > Max >
