Sorry my previous reply fell of the list ... here is a proposal for a
"refreshed" Repository interface:
public interface Repository {
/**
* Search for the DataAccess (or DataStore) providing access
* to the indicated typeName.
* <p>
* This lookup method is not namespace aware; and will find the first
* possible match.
* <p>
* @param name Name of the DataStore to retrieve
* @return DataStore
*/
DataAccess<?,?> access( String typeName );
/**
* Search for the DataAccess (or DataStore) providing access
* to the indicated typeName.
*
* @param Name The typeName (namespace and name) to search for
* @return DataAccess api providing access to the
indicatedTypeName (or null if not found)
*/
DataAccess<?,?> access( Name name );
}
A couple changes from yours:
- DataAccess is returned rather than DataStore
- namespace is part of Name
I find this a little weak in that you cannot "browse" the contents of
the Registery; however since we do not have a need for that - only
look up - I think we are fine.
I find it really stange that you are lookin up DataStore here; by the
typeName the DataStore produces. A code example would end up being.
Name typeName = new NameImpl( namespace, name );
DataStore<?,?> data = (DataStore<?,?>) registery.access( typeName );
FeatureSource<?,?> source = data.getFeatureSource( typeName );
I would find it easier with a single registery.source( typeName )
method; but whatever. I might also suggest a dataStore method to avoid
the cast to DataStore.
So how about it; if I make this modification can we update your code
(and implementation) to make use of it?
Jody
On Thu, May 14, 2009 at 10:33 PM, Jody Garnett <jody.garn...@gmail.com> wrote:
>> Jody I took a deeper look to Catalog interface and I got dazed and confused.
>
> Not the catalog interface the simple repository interface ...
> interface {
> Map getDataStores();
> SortedMap getFeatureSources();
> Set getPrefixes();
> boolean lockExists(String lockId)
> boolean lockRefresh(String lockId, Transaction)
> boolean lockRelease(String lockId, Transaction)
> source source(String dataStoreId, String typeName )
> }
>
> And you have:
>
> public interface DataStoreLookup {
> public void initialize(Object source);
> public DataStore getDataStoreFor(String name);
> public DataStore getDataStoreFor(String namespace, String name);
> }
>
> So one is working with FeatureSource and the other is working with
> DataStore; incidentally how do you look up a datastore for a
> namespace/name ? does that not indentify a single feature type? I also
> do not know what your initialize( source ) method is for ...
>
>> Again I agree on having a central repository interface but a redesign is not
>> a matter of adding some methods.
>
>> Some thoughts
>> 1) I am missing the clean concept of namespace handling
>
> Then we add it; right now the api documents something stupid - a
> datastore id since that is what geoserver had when it was written.
> Which each have a lookup method that takes two strings - both are
> supposed to be a simple front end to the geoserver catalog so they
> probably end up acting the same.
>
>> 2) It must be possible to write a Repository implementation acting as
>> adapter for the geoserver catalog (supporting the workspace concept, which I
>> think we could handle with 1). The same must be possibile for UDIG. The
>> interface implementation must be configurable externally, we need something
>> like a "RepositoryFactory"
>
> Ignore uDig for a moment; focus on what geoServer is doing; I can make
> udig work later.
>
> I did not follow you their; you probably intend to pass in this
> repository as a connection parameter to your pregeneralized datastore?
> Something either application can do.
>
>> 3) Unlucky naming of methods, "source" as an example. You must look at the
>> source code to have an idea what this method is doing. Missing methods, how
>> to get a datastore with his name and namespace ?
>
> You are focused on name and namespace; that is fine. Source is the
> super type of FeatureSource (something gabriel did). I am not sure if
> your datastore is generic enough to work on Source (does it assume
> simple features or not?).
>
>> 4) No idea about the locking methods, I think nobody calls them, and btw, I
>> would delegate the locking to an
>> external locking manager. And why should a repository do locking at all ?
>
> We can remove them; the reason locking had the responsibility was
> because it was the only interface that "knows" all the datastores and
> thus can perform cross datastore operations (such as locking).
>
>> So, I think we would a least need
>> RepositoryInterface
>> RepositoryFactory
>
> I think we can skip the factory on this one; we are not creating a
> generic Repository; we are being passed in an adapter to the geoserver
> catalog.
>
>> RepositoryImpl for geotools
>
> This is pretty simple to write; just store the datastores in a map.
>
>> RepositoryImpl for geoserver
>> RepositoryImpl for udig ?
>
> These other two seem okay.
>
>> This would be a real improvement but it would block me for weeks.
>
> I do not want to introduce duplicate api for the same function; would
> you like to have a breakout IRC session and fix the repository
> interface to match your datastore finder? You do have to explain your
> two part namespace / name lookup - looking up a DataStore for me;
> right now that makes little sense to me.
>
>> As a proposal, I would like to continue with the DataStoreLookup and mark it
>> depricated as soon we have implemented a cleanrepository concept.
>> christian
>
> I am interested in going the other direction; replacing the Repository
> interface methods with what you have in DataSource lookup. Part of the
> difficulty here is that your module "introduces" public api - not
> simply implementing the DataStoreFactory (which can be dropped into
> any app; but instead asks to go out into the app that is hosting it
> and look up other datastores).
>
> Jody
>
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
