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. ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
