Thinking out aloud... what if we have the same feature type being delivered by multiple stores - for example a common gazetteer view of the different feature types. Or sometimes we have several sub-types, and we want to provide a single view using a supertype.
This situation does occur in practice from my experience with defined schemas being used. we'd need a despatcher to route queries to the right data store, but it would be a shame to get the resource/publishing split making the assumption that one FeatureType = 1 datastore. Namespaces only exist in the external contract. Its only the fact that they may be "known" to the client that gives them meaning - otherwise you might as well generate random unique names for everything. Rob On Wed, Jun 17, 2009 at 12:38 AM, Justin Deoliveira<jdeol...@opengeo.org> wrote: > Hi Andrea, > > Andrea Aime wrote: >> Hi, >> I'm getting tangled in a seemingly simple issue. >> I want to know if a FeatureTypeInfo with a certain >> name is available in the catalog already to avoid >> duplicates. >> >> Now, logics tells me there should not be two feature >> types with the same name in the workspace. Right? > I think so. Or do we want to qualify feature types by the name of their > store? Given that we qualify by namespace today it might make more sense > to make them workspace unique. Sorry... thinking out loud here. >> >> However, the catalog uses a namespace qualified name. >> Right, a WFS server should never publish two layers >> with the same namespace and same local name. >> >> But isn't the namespace a publishing property, and >> so something that should be set at the layer >> level? So how do I search the feature types? >> Looking them by namespace seems wrong then? > It is, or more it *should* be. I guess for now we just continue with the > way things are using namespace, and since namespace is 1-1 to a > workspace, we can continue to ride that assumption. When we have > resource-pub, we deprecate the getResourceByName methods which take a > namespace, and change them to take a workspace. >> >> Boys, this incomplete data/publishing split is giving >> me a headache ;) >> > Your not the only one ;). I have been working toward implementing the > proposal that was done up a while back... work is slow going though. > > -Justin >> Cheers >> Andrea >> > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > ------------------------------------------------------------------------------ > 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 > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > ------------------------------------------------------------------------------ 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 _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
