I refactored the module on 2.5.x and 2.6.x to use the Repository inteface and kicked off my DataStoreLookup interface.
You can see the changes also in the geotools user guide documentation. So far, I have +1 from Andrea. Would the "library" directory be the right place ? Jody Garnett writes: > I am on 2.6.x not 2.5.x (so you may need to think when applying the > patches to 2.5.x?) I generated the patch with svn diff so it should > not be that effected by platform. > > I have created a bug report here: > - http://jira.codehaus.org/browse/GEOT-2486 > > I will see if I can apply the changes to 2.5.x for you. > Jody > > > > On Fri, May 15, 2009 at 4:51 PM, Christian Müller > <christian.muel...@nvoe.at> wrote: >> I cannot apply your patches. All 3 files report errors when applying with >> patch -p0 < patchfile >> I am up to date with 2.5.x repository >> No idea, I think you are sitting in front of an M$ box, I am working on a >> linux box. Converting with dos2unix does not help either. >> Can you try it agein after an "svn up" on 2.5.x or send me the java files. >> thanks >> >> Jody Garnett writes: >>> >>> Just to follow up - Christian and I sorted out some things over IRC; >>> and he is reviewing a patch right now. >>> Jody >>> On Thu, May 14, 2009 at 10:52 PM, Jody Garnett <jody.garn...@gmail.com> >>> wrote: >>>> >>>> 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 >>>> >> >> >> ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
