Antonello Parente ha scritto: > > >> >> >> *Oggetto: **Re: [Geoserver-users] Updatable Postgis Views with WFS and >> Geoserver* >> >> I would like to participate in the implementation of this feature. >> Where do I start?
Hi Antonello, sorry for the late reply. I think the first step is to think about a design for this new feature. Here are my thoughts, hope that other developers will chime in. At the datastore level we could have a strategy object that can be used to figure out the nature of primary keys and the associated sequences (if any). Just an interface that gets injected in the datastore. This way we could have multiple implementations of it based on the various needs. One could be based on the lookup tables I was talking about, and would not need the intervention of any user interface. Another one could be GeoServer specific and injected in when creating the datastore, and could be GS aware, have a reference to the catalog and its configuration. The UI you proposed could store the configurations in the FeatureTypeInfo user map, and use that to determine the primary key information at run time. We also have to roll out some API to refresh the datastore feature type cache somehow (the jdbc datastores do keep a cache of this metadata since it's expensive to determine it on a request by request basis). This approach would allow for a pluggable configuration object (do we have callbacks for when the resource pool sets up a datastore? Maybe not, but it's probably a good idea to add them?). What do people think? Alternative plans, suggestions? Cheers Andrea >> Regards >> Antonello >> >> Il giorno 21/ott/2009, alle ore 07.25, Andrea Aime ha scritto: >> >>> Antonello Parente ha scritto: >>>> It is a great IDEA...! >>>> We need a radio button in add layer jsp page to specifie column metadata >>> >>> eh, what you're suggesting is much more complex to realize. >>> We'd have to modify the datastore itself (like in the idea I proposed) >>> and then modify the Gs configuratoin classes, the user interface, >>> and introduce some code that reconfigures the datastore every time >>> it's reloaded with that feature type per feature type information. >>> >>> That is a few days of work, definitely requires sponsoring (or someone >>> willing to do it). Any takers? >>> >>> The approach of using lookup tables instead hits only the datastore >>> and is thus easier to implement, much less work, one day or something >>> like that. I'm not saying there are resources right now to look into >>> it either, but it's certainly easier to find either funding or >>> resources that way >>> >>> Cheers >>> Andrea >> > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
