On Fri, Oct 1, 2010 at 10:13 AM, Rini Angreani <rini.angre...@csiro.au> wrote: > > Hi Andrea, > > I also thought that the main reason to use feature chaining like you said, > is to avoid managing large denormalised views. The table/view gets really > big when you have deeply nested features (sub features that have also have > features), especially when multiple multi-valued properties are involved (in > sub features). Although, according to Ben, it wasn't possible to map > multiple multi-valued properties using grouping alone (without feature > chaining). Sorry, I don't fully remember the limitations of grouping in old > app-schema. Anyway, the whole grouping mechanism has been removed now, but > still remains in 1.6, so if multiple multi-valued properties are involved, > feature chaining must be used for 2.0 and beyond.
So in the current one it's possible to have multiple multivalued properties and still use a single table? > I played around with the alternative solution you proposed a while ago, i.e. > querying by fids, but when the dataset gets really large, we ran out of > memory pretty quickly (having to store the fids somewhere). Yep, pretty understandable. What you can do is to use paging: retrieve the fids, store them on disk temporarily using a data output stream, then for each sub query you have to run get, say, 1000 of those fids and run a first query, then repeat for the next 1000 and so on. This should avoid keeping in memory a large list of fids and at the same time avoiding too large queries. Do you happen to have your experiments somewhere? I'd like to have a look at that code. > The only current plan to improve performance is to possibly halve the time > it takes, since the queries are run twice (1st one to get size or > numberOfFeatures printed on the header, and then to actually encode the > features). This makes sense for simple features, because they're streamed, > so getting numberOfFeatures before encoding is straight forward. Anyway, > even when this is fixed, it's still not fast enough. > There is a plan for improving the performance properly (on the database join > level or using hibernate), but not in the near future. Pity :-) Cheers Andrea ----------------------------------------------------- Ing. Andrea Aime Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584962313 fax: +39 0584962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ----------------------------------------------------- ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
