That was a good post Justin. Enjoyed readin it to the end. Without speaking for Ben and Rini, who now has a much deeper understanding of the way schemas are used in app-schema, I will comment on the underlying requirements.
Firstly, the application schema imports all its dependencies explicitly. Implementations of a particular feature type do not necessarily, however, exercise all imports. Some imports are however required as base classes, and others for attribute types. So you cant just look at a feature type configuration and determine the dependencies - you really do need to look at the application scheam. The pattern for a Feature relationship allows "inlineOrByReference". Feature chaining provides a means to decouple the actual schemas, but we build the schema from the XSD on startup, so I'm not sure this make much practical difference. The point is, the configuration choice of FeatureChaining determines what schemas are actually dependencies. so, the final set of schema depdendencies are a function of both the application schema type hierarchies and the configration choices. App-schema loads the entire schema, then builds the feature type model from the configuration. Describe Feature Type should just deliver the original schema used in the configuration. I dont see why scanning this catalog should be a problem - its static (in the configuration vs, run-time sense - not Java Static!), so it shoiuld be possible to create an index at configuration time. The amount of memory it uses for a large schema is an issue - but manageable - we simply need to configure deployments appropriately. In the case of an "ad-hoc" schema, an artefact of configuration, there are no dependencies. The schema is defined at configuration-time and I would guess needs to be cached in its entirety. Each one is unique to a configuration. App schemas are defined externally. So I dont understand why you would ever build a schema that links feature types together. App-schema does this using the pre-built schema, and its not supported by ad-hoc (pseudo-)simple features. I suspect there are other issues at play here that I dont really understand - like modifying the internal model of the WFS schema to allow collections of user-defeind feature types? rob On Tue, Feb 16, 2010 at 9:53 AM, Justin Deoliveira <jdeol...@opengeo.org> wrote: > Hi all, > > Continuing from the thread about improving WFS performance I need to get > some input from the appschema experts. > > Since the appschema extension supports relationships among feature types > there are now dependencies between feature types. My question is is > there any way know what the dependencies are? > > The reason I ask relates to trying to prevent building a schema for > encoding purposes that contains all the types in the catalog. Consider > doing a getfeature request against type X where type X has attributes > that are instances of features of type Y from another namespace. > > Consider a getFeature request against type X. Now if type X was simple > there would be no link and I could simply build a schema that contains a > single complex type and everything works great. But in the complex case > I also need to build that schema so that it > imports/includes/incorporates type Y as well. > > So again the question is how do I infer this dependency given a > FeatureTypeInfo object representing X? Is this information buried within > the depths of the appschema datastore? > > -Justin > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > ------------------------------------------------------------------------------ > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
