Hi,
I was wondering about how 2.0 stores layer attributes in the data directory as opposed to how 1.7.x used to discover them at runtime.
While there is a strong case for storing the attribute information and relying only on that in production, this causes a bit of a headache in development. Iteration costs are a lot higher when one needs to re-create the layer every time you change the data source (table or view in my case). Not only does it take more time than just reloading the configuration but it’s error prone as you need to re-enter all information (bbox, srs, names, styles, etc.). Then there’s the fact that you can’t reload the configuration anymore - you have to restart the entire server process (unless you do some black magic).
All in all, the new version seems to work well, but the development workflow has slowed down quite a bit. I’d love if these workflow issues would be looked at seriously after 2.0 is released. In my view, it could be a good idea to have a “production mode” and a “development mode”. The first one would use the layer attributes in the data dictionary and possibly disable the console altogether while development mode would discover attributes at runtime.
Sampo Savolainen
Hi, good feedback.
There's a development mode flag that, of the things you need, will allow you to reload the configuration. If you run with -Dwicket.configuration=development you'll get an extra sidebar panel with some developer options. More of them could be added, like clearing the attribute type caches... not sure the implicancies though.
Hope that helps,
Gabriel
Savolainen Sampo wrote:
Hi,
I was wondering about how 2.0 stores layer attributes in the data directory as opposed to how 1.7.x used to discover them at runtime.
While there is a strong case for storing the attribute information and relying only on that in production, this causes a bit of a headache in development. Iteration costs are a lot higher when one needs to re-create the layer every time you change the data source (table or view in my case). Not only does it take more time than just reloading the configuration but it's error prone as you need to re-enter all information (bbox, srs, names, styles, etc.). Then there's the fact that you can't reload the configuration anymore - you have to restart the entire server process (unless you do some black magic).
All in all, the new version seems to work well, but the development workflow has slowed down quite a bit. I'd love if these workflow issues would be looked at seriously after 2.0 is released. In my view, it could be a good idea to have a "production mode" and a "development mode". The first one would use the layer attributes in the data dictionary and possibly disable the console altogether while development mode would discover attributes at runtime.
------------------------------------------------------------------------
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
This has been discussed on the mailing list and IRC before and it is agreed that storing the attributes as regular properties was indeed a bad idea. A patch has been developed for it:
http://jira.codehaus.org/browse/GEOS-3294
However at the time it was decided that the patch was a bit too major to get in so close to 2.0, although in reality that was quite some time ago.
So bottom line is at some point this will be restored back to the original state. As for when, i leave that to the powers at be to decide.
-Justin
Savolainen Sampo wrote:
Hi,
I was wondering about how 2.0 stores layer attributes in the data directory as opposed to how 1.7.x used to discover them at runtime.
While there is a strong case for storing the attribute information and relying only on that in production, this causes a bit of a headache in development. Iteration costs are a lot higher when one needs to re-create the layer every time you change the data source (table or view in my case). Not only does it take more time than just reloading the configuration but it's error prone as you need to re-enter all information (bbox, srs, names, styles, etc.). Then there's the fact that you can't reload the configuration anymore - you have to restart the entire server process (unless you do some black magic).
All in all, the new version seems to work well, but the development workflow has slowed down quite a bit. I'd love if these workflow issues would be looked at seriously after 2.0 is released. In my view, it could be a good idea to have a "production mode" and a "development mode". The first one would use the layer attributes in the data dictionary and possibly disable the console altogether while development mode would discover attributes at runtime.
------------------------------------------------------------------------
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Gabriel Roldan ha scritto:
Hi, good feedback.
There's a development mode flag that, of the things you need, will allow you to reload the configuration. If you run with -Dwicket.configuration=development you'll get an extra sidebar panel with some developer options. More of them could be added, like clearing the attribute type caches... not sure the implicancies though.
We should really provide that link in some admin panel so that the
Wicket development trick is not necessary.
The server status for example?
A reloader REST call would be very handy as well (or do we have
one already?)
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.