From: Chris H. <ch...@op...> - 2003-09-29 15:16:37
|
Hmmm...tried to send this Saturday, which would have been more timely, but some mail server didn't like it... > - The most part breaking my head is that I found the FeatureCollection's > model not very appropiate for real world applications, since > almost all implementations I have seen loads the full amount of > features > into memory prior to processing it. This is because we fairly recently redid FeatureCollections, with more of that design in mind, but no one has time to make better implementations. The original thought was to have datasources provide their own FeatureCollection implementations if they could, so that a PostgisDataSource would return a PostgisFeatureCollection, which would be backed by a result set. That thought is now getting refined as we all think about it more, with the flyweight datasource and IanS's new attributeReaders, breaking up the parts of the DataSource interface so that each DataSource doesn't have to implement its own FeatureCollection, we can have better FeatureCollections that use the new datasource api pieces. > That's why I was working in a "flyweight" version of this datasource, > but although it works fine (very) for fast and read only pass throw > operations such as exporting to another format, it still smells much > like a workarround instead of a good implementation... > > After all, this has to do with DataSource (and FeatureCollection too, > IMHO) design issues discussed in part in last IRC meeting (unfortunatelly I > forgot to presence due to brain flat line signals) I spent wednesday and thursday looking over IanS's new ideas, trying to figure out where he's headed and how it would fit into Postgis. I came up with a basic implementation of AttributeReader backed by a ResultSet from a postgis sql call. My work can definitely use improvement, but it was a good exercise to get a feel of what IanS has in mind. I do like the ideas behind it, as the DataSource api is too massive. The main thrust of his thoughts are to break it down into common parts, which can then be more easily used to build things up. I too was a bit scared that he was envisioning massive changes, but most of his concrete ideas are very reasonable, and the more abstract ones are more directions for discussion of things DataSource needs to do but either does badly or not at all right now. So I think we're on the right track, but the problem is we need a lot more input and thought. The previous design changes in DataSource were primarily driven by the needs of GeoServer, and GeoServer in its beta stage, when we did not care so much about efficiency, only spec compliance. But the DataSource API needs to be thought through much more than that, so as to make geotools flexible enough for all users. I think most of us are thinking more or less the same things that need to get done, but we need to sit down and figure exactly what the api is going to be. IanS did an excellent job of getting the ball rolling, but at the end of our discussions we realized we need everyone to weigh in on this. So we were thinking that the best thing to do is probably a break-out DataSource irc discussion, where we can hopefully agree on a time to get everyone there. The current IRC time is awful for Sean, and I think it's very important that he participate, as his oracle datasource work has been driving jdbc datasource improvements for awhile. And I think IanS mentioned that he was going to miss Monday's IRC, and we need him there for discussion as well. So if people could email the list (or me) with good and bad days and times for meeting next week then we can hopefully finalize a meeting time during monday's IRC. Chris (And now monday is today and the email didn't get out, but let's still try to figure out a meeting time soon.) |