Hi,
I'm thinking of backing out the directory data store because it has
multiple issues.
First, it does not handle namespaces, and the framework has no way of
imposing a namespace on a child data store.
There are two ways to fix that: the first is to change FileDataStoreFactorySpi.createDataStore(URL) to accept a namespace,
but that would mean breaking an interface in a stable branch...
Second option would be to do the necessary wrapping, that is, forcing
the right namespace in all places where feature type and features
are returned. This can be done, but it requires the back port
of 4 classes from trunk, since I need to wrap the returned features source, store and locking, as well as every feature collection returned,
to perform the feature type mapping.
I don't mind the work, but I'm wondering if this is ok for an RC.
Plus, consider that directory data store loads feature types on startup,
to make it useful we would have to make it watch the directory and
invalidate the feature type list each time the directory contents
changed.
So, what do you suggest?
Cheers
Andrea
I think my preference would be to back out directory data store for 1.5.0 since we are so close to release.
Correct me if I am wrong but it seems that changing the interface is the easiest approach. Perhaps we could plea for a special case here. Or perhaps we can be sneaky and add the method to all the implementations and do the call reflectively so we don't have to change the interface :).
-Justin
Andrea Aime wrote:
Hi,
I'm thinking of backing out the directory data store because it has
multiple issues.
First, it does not handle namespaces, and the framework has no way of
imposing a namespace on a child data store.
There are two ways to fix that: the first is to change FileDataStoreFactorySpi.createDataStore(URL) to accept a namespace,
but that would mean breaking an interface in a stable branch...
Second option would be to do the necessary wrapping, that is, forcing
the right namespace in all places where feature type and features
are returned. This can be done, but it requires the back port
of 4 classes from trunk, since I need to wrap the returned features source, store and locking, as well as every feature collection returned,
to perform the feature type mapping.
I don't mind the work, but I'm wondering if this is ok for an RC.
Plus, consider that directory data store loads feature types on startup,
to make it useful we would have to make it watch the directory and
invalidate the feature type list each time the directory contents
changed.
So, what do you suggest?
Cheers
Andrea
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Justin Deoliveira ha scritto:
I think my preference would be to back out directory data store for 1.5.0 since we are so close to release.
Correct me if I am wrong but it seems that changing the interface is the easiest approach. Perhaps we could plea for a special case here. Or perhaps we can be sneaky and add the method to all the implementations and do the call reflectively so we don't have to change the interface :).
Well, the proper thing to do would be to deprecate the current implementations, create a sub-interface that adds the method we need, make everyone implement it. That would work, I just could not think about it yesterday.
I must say that in fact only three classes do implement that interface,
so they're not "all" of the file based data stores. Unimportant one it seems, still breaking an interface is something that gives me the
shivers (poor users are already constantly fighting our changes, I
don't like much the idea of adding more).
Yet, changing the interface would probably solve the issue for
Geoserver, but would not be a fully correct solution.
Say I ask for a feature source to the directory data store,
then ask the datastore to the feature source, and I'll get the
wrapped one because directory data store returns the feature source
it gets as is, without wrapping it.
Cheers
Andrea