Rob Atkinson ha scritto: >> Last time I checked application-schema datastore was read only? > > Yes it is, but we should discuss this as part of the next steps strategy work.
This is sure interesting. Do you have a longer term plan about this? >> And GeoServer must do WFS-T. What I really want is something that >> allows me to rename attributes and map types on simple features >> without: >> 1) getting a significant drop in performance >> 2) loosing the ability to write > > This is perfectly reasonable set of objective criteria - its always > reasonable to put in optimisations for common special cases, but best > to do this against a design capable of handling all cases that will > matter. In an ideal world, yes, but practice does not always agree with that. The "general" case architecture usually has to do a lot more work in order to deal with its generality, sometimes you can just add a few checks in core places and you get the best bang for the buck... and sometimes its clear that performance was not considered during design and it's simply impossible, or too hard, to retrofit it later. >> If the application schema datastore can evolve to this point, >> excellent, otherwise I'll roll out something simpler that handles >> efficiently and effectively the common and simple case. >> > > Its obviously expected that you will need to do this - the questions are: > 1) can this be removed easily enough if a general solution emerges? The current RW type renamer is just a wrapper around datastores and feature collections. It could conceivably be evolved into something that does simple renaming and type mapping keeping a decent performance profile and without loosing RW capabilities. As for easy of removal, it's currently hooked up into the FeatureSource building chain by something like 15 lines of code in a single method of ResourcePool. Cannot get any easier to remove than this. > 2) does rolling this out involve adding unsafe or unnecessarily > restrictive assumptions into parts of the code base? Hmmm... I would not think so. If we ended up doing this the harder to switch out part would be the mapping configuration. But for sure I would make it so that it follows the current design principle: _nothing_ outside of the classes that build up the FeatureSource for the rest of GeoServer would know about it. The rest would just play ball as usual, not knowing that the FS it's playing against is actually a dynamic feature mapper. And I want this kind of design for application schema as well. Granted code modifications are needed to support complex features, but I really do hope we won't have to make changes in services to support application-schema mapping (besides the WFS references to external, non GS generated schemas). Cheers Andrea Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
