On Mon, Oct 4, 2010 at 7:14 PM, Justin Deoliveira <[email protected]> wrote: > Hi all, > I have been trying to solve this issue various ways for a couple of days now > and would like some feedback from others. > Now the issue in question here is supporting lazy loading and the layer edit > page which contains multiple tabs, one for the resource and one for the > layer. This page uses two models for hanging onto the REsource and Layer > respectively. And the models store the object directly, instead of the > loading them from the catalog. And for good reason, this is done to maintain > edits while the user switches between tabs. > Now where the problem comes up is with dbconfig and lazy initialization. > Once a page reload occurs the layer and resource are serialized. However the > objects contain lazy lists and association proxies that were created by > hibernate as a result of lazy loading. So when they get serialized the > session in which they were created is gone and they no longer function. > I tried solving this one a couple of different ways with varying degrees of > success. Here is what I tried: > 1. Instead of store the objects use a map as the backing for the model > I actually did not get far with this one. It became evident very quickly > that this would require a lot of changes > 2. Make each tab independent and forget about allowing the user to maintain > changes between them > This one would involve changing the models back to models that load from the > catalog rather than serialize the objects directly. And making each tab save > independently. While this works we give up the ability to make changes on > both tabs, switch between them and save. So the workflow takes a hit. Plus > Andrea worked very hard to make that functionality possible so it would be a > pity to throw it away. But i raise it as a possible solution. > 3. Add some catalog api to "dettach" the object > Currently the backing models for the patch call an "attach()" method on the > catalog builder to set the catalog on the resource and the layer, since the > catalog reference is transient. So what I thought of was using something > similar. Not so much an attach but a dettach. The dettach would basically > reload the object without lazy loading using a custom query of sorts. Then > serialize that result. And it seems to be working for the most part. > Although in some sequences of edits i have run into other issues around some > proxies not being properly initialized. > So any thoughts? (3) seems to be the most promising at this point and does > not require many changes to the page in question. But does not require some > new catalog api. > Feedback welcome. Or if any of those wicket experts out there have any ideas > they would be welcomed. I did some searching in the wicket forums and did > not find all that much surprisingly. Most often the answer is "do not use > lazy loading" :(
Time allowing the third option seems the best one. Mind one thing, there is a further user of those models, it's the sql view edit page. I had to modify the layer pages quite a bit to make that one work as well: it's tricky, because when you submit a change in that page you go back into the layer one and the change made to the feature type does not have to go into the catalog just yet, but only when the user actually submits from the layer page. Yet, the feature type structure displayed has to be updated according to the new sql view definition, and to do that you have to make a direct call into the resource pool I believe. Cheers Andrea ----------------------------------------------------- Ing. Andrea Aime Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584962313 fax: +39 0584962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ----------------------------------------------------- ------------------------------------------------------------------------------ Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
