Ben Caradoc-Davies ha scritto:
On 04/06/10 14:15, Andrea Aime wrote:
Wondering if you can open a Transaction, set it into the feature
sources, so that all of them operating against the same db will
share a single connection. That would improve the scalability
significantly....
A more difficult problem is orchestrating multiple filter queries so that a single complex feature WFS response can be built from multiple simple FeatureSources, where the FeatureSources interact to reassemble the filter queries into an efficient join.
The implementation of app-schema builds on the existing simple FeatureSources, one FeatureSource per table/view. This makes navigating relationships very inefficient, because GeoServer has to take the simple features and find their relationship so they can be reassembled into a complex feature, with one as a nested property of the other. This typically involves making a new filter query for each complex property of each enclosing feature (yes, you read that right, feature, not feature type). The volume of the generated SQL can exceed the volume of the encoded response. This query pattern would be more naturally and efficiently represented in SQL by a JOIN on the fields defining the relationship.
The obvious better way it to implement native joins in the data stores,
and that will help you in the common case of all data sources being
stored in the same DB.
However, it's possible to make a join with only two queries (yes, only two) under certain conditions:
- no external sorting is required
- both sides support sorting
- it's a 1-n join
In that case you query both sources sorting on the joining key (assuming
the usual fk driven equijoin) and scan over them pairing the keys
and moving forward the 1 collection only when the n collection joining
key changes.
Well... not the best explanation, but I hope I got the message though.
So, is it possible to take a complex information model, flatten it into a collection of simple feature types, and reassemble it just in time to make an efficient SQL query appropriate to the complex information model? (And pass the result back through the simple FeatureSources). My gut feeling is no.
Query flattening is one of the Hibernate strategies actually.
You have N tables to query, it makes a massive outer join style query
with proper sorting and then scans that single result to build
an in memory object tree. Same reasoning as above, but requires joining
(outer join style) in the data stores to be carried out.
This is in my view one of the fundamental architectural limitations of GeoServer app-schema. Even thinking about it leads me into wondering whether we end up trying to solve the general object-relational mapping problem.
Andrea, have you got an experimental git local repo that does this? 
Nope.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
