Ben Caradoc-Davies ha scritto: > Andrea Aime wrote: >> First a question, is does data access finder pick up data stores too? >> It should, since a DataStore is a DataAccess. > > This is not a given (I don't think SPI considers inheritance), but it > should work because DataAccessFinder.getAllDataStores goes out of its > way to call DataStoreFinder to get all the DataStoreFactorySpi > implementations as well as the DataAccessFactory implementations.
Hum, ok, that does not sound like a big problem anyways. >> If so, I guess a limited patch could do the job: most of the >> code accesses the catalog in search of a FeatureSource/Store, >> and DataAccess provides them, so most of the intermediate code, >> that is, the code that builds up queries, maps and the like >> should keep on working untouched. > > We will also need to get the web configuration interface to ignore > DataAccess implementations until it can handle them. Correct. >> What needs modifications is whatever deals with FeatureType and >> Feature, and there we have to be very very careful, to avoid >> putting the code into silly slow code paths when that is not >> necessary (my expectations are that the careful part will have >> to be Feature manipulation, FeatureType wise it'll be slower >> but not to a point it can be noticed). > > Would you be happy with instanceof tests, or can you recommend a better > pattern? Strategy, perhaps? Ideally speaking, choose an optimizer accessor before starting to work on the feaures, and then keep on using that one for the whole encoding session. This is what the PropertyName impl already does, in a way, it caches the last used accessor... not ideal, since it has to second guess itself and check every time if the accessor is still good, but usually good enough. For XML encoding for example it would be nice to have a Feature binding and a simple Feature binding, or yes, just do an instanceof at runtime, since instanceof is blazing fast. I guess we'll have to decide on a case by case basis trying to get a balance between cleanness and resources required to implement a certain approach. >> So what I'd like to see is a set of incremental (small) patches >> that do unlock the usage of DataAccess and complex features >> one bit at a time, going up from the catalog unto the >> output producers. >> It would be nice if each patch could be reviewed and then >> committed. >> I also expect to see tests, so that we can prove stuff >> is working and will keep on working as GeoServer evolves. > > For testing purposes, it might be necessary to write a skeletal (for > example) TestDataAccess, so that GeoServer does not depend on > app-schema. In fact, this is where we should start (test-driven > development). Sounds good to me. >> Can the complex data store be used on top of one or more property >> data stores? This is how we do functional testing now, and >> works very nicely because there is no need to setup external >> databases. > > Yes. It uses any DataStore. Most of the app-schema unit tests use > property files. Great! Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
