Re: [Geotools-devel] DataSource.getSchema() advice needed

[Chris H. <ch...@op...>]

>  > My questions is:
>  > What should I return as schema first?
>  >
>  > Should it be list of available libraries or list of all available coverages?
>  > And what type should I set
>  > for FeatureType?
>  >
> 
> This seems to be a database. So, well, this is how I'd create the datasource:
> * the VPFDataSource constructor should get the vpf file path, the library
>    name and the coverage name. This datasource will allow for retrivial of
>    only the coverage specified, so that you have a single bbox and a single
>    and simple FeatureType.
> * create a VPFDatabase class that is used to retrieve some metadata from
>    the file, that is, the list of libraries, and the list of coverages for
>    each library. This class is useful to gather the necessary metadata in order
>    to instanciate a VPFDataSource.
> 
> An alternative approach:
> * the VPFDataSource constructor only gets the vpf file path. There are
>    a getLibraries and a getCoverages(libraryName) to query the vpf content,
>    and a setCurrentCoverage(library, coverage) that set the coverage to be
>    read. The datasource defaults to the first coverage in the first library
>    if nothing else is specified. getBBox, getSchema, getFeatures and so on
>    work only on the current coverage.
>    Providing support for modification methods is not easy to do in a generic
>    way thought, in a sense that setFeatures should immediatly save the
>    data, but in this case you may want to delay disk writing until you have
>    set the content of all the libraries and all the features (or maybe not,
>    I don't really know anything about vpf).

Sorry I've been quiet on this stuff...I've been trying to get a release 
out.  But quickly, I agree with Andrea, that it seems to be more of a 
database, and you can think of each of the coverages as tables in that 
database.  Therefore each datasource created should only hold one 
coverage, and its getSchema should return the schema for one featuretype.  
In time, we might have geotools datasources handle more complex features 
and schemas, like a schema that includes all of the different featureTypes 
for a database.  But for now we just make the simplifying assumption that 
a datasource only has one featureType.  To be consistent with the current 
geotools datasources, I'd say follow Andrea's first suggestion.  The 
VPFDatabase class could function similar to how PostgisDataSource uses 
the connection object, and you could then provide functions in the 
VPFDatabase class similar to the jdbc DatabaseMetaData object as well, 
such as the getLibraries and getCoverages that Andrea was suggesting.  

This would lead to two possible ways to use the VPFDataSource - 
1. I just know the location of the vpf file.  So I make a VPFDatabase, and 
then get its libraries and coverages, and figure out which one I want.  
When I know which one I want I create the datasource - the constructor 
would take the name of the coverage (and library?  not sure how it works), 
as well as the VPFDatabase (or just the location of the file.)

2. (This is how I'd use it with the GeoServer wfs)  I know the name of the 
coverage that I want, so I just call the constructor directly with the 
location of the vpf file, and the name of the coverage (and library?  I 
would know that too).  This way would allow use of the automatic database 
discovery mechanism - the user would just input the params - file 
location, library name, and coverage name, and the factory could then 
generate the appropriate datasource.


Actually, artur, you should probably just start out with way 2, and maybe 
not yet bother with the VPFDatabase.  Postgis doesn't really do way 1, 
unless a user is very smart with jdbc Connections and Metadata, where they 
could figure out what the other tables in the db are.  So yeah, just limit 
the datasource to one coverage at a time, the constructor always takes a 
coverage name, and getSchema just returns the featureType for that schema.



And then we can start talking about how we handle more complexity.  It 
will be good to have your insight on vpf, since right now we only have two 
datasources that are developed to a good enough degree to add to our 
discussions.  But I do feel that for database type datasources we should 
have ways to discover all the information they hold, so you could just 
use the plug-in datasource mechanism, and then figure out what features 
you _could_ get from the datasource, and use them appropriately, instead 
of limiting ourselves to have the user know beforehand what the datasource 
holds.  Perhaps we could adapt the metadata object to do it for us...file 
datasources with only one featureType would just report the one available, 
jdbc connected datasources could use their getTables methods on the 
connection's DatabaseMetadata, and the vpf could provide it's own custom 
implementation.  I have more ideas on how to do this, but I must get back 
to my release, as today is the day.


Chris