Rob Atkinson ha scritto: > I dont think we disagree - we're just looking from the problem from very > different perspectives. > > I just dont like calling a database table or result-set a FeatureType. > A feature is a representation of a real world concept defined by a > community. I'm happy to call it a "View", or maybe a better name. It > seems the argument stems from my obstinance in this matter.
Yes, here we disagree :-) From my point of view, what a community defines is a formal data exchange format. The structure of a database or a shapefile has the same dignity in my eyes, even more, because it's used to drive real applications. Someone designed it, maybe badly, but in a way that served practical needs. The only thing a community may agree with is a public interface, the internal representation will probably be different for performance and technological considerations. > I'm agnostic about the implementation specifics, but in general I think > we should aim at, for simplicity across the range of issues: > > 1) Abilty to stream features during simple processing chains > 2) Hence, default behaviour of reading all the attributes required to > create the feature > 3) Not necessarily post-processing attributes - e.g. converting strings > into dates or vice versa unless required - i.e, _allow_ but _do not > force_ lazy instantiation of feature properties from the result set. > 4) Minimise actual retrieved data by taking into account the target > FeatureType, not the underlying persistence store which may contain much > else. This is already what we're doing in JDBCDataStore, when it's possible. ReTypeFeatureReader it's there for: * datastore where you cannot limit the number of attributes you're reading (maybe just because of implementation simplicity considerations); * datastores where you cannot natively encode part of the filter, so you have to load a bigger feature, apply the extra filter, and > Perhaps we could start off with a default strategy of: > * read and resolve simple scalars (current strategy, where "implicit > mapping" means we need to real all attributes.) > * resolve expressions lazily > * read and resolve gml:FeatureTypeProperty properties lazily unless > mapping provides a hint > * read and resolve expensive (eg blobs, XML docs) lazily (not that we do > this at the moment anyway) We could do that, but would the extra code complexity, the extra understanding and mantainance costs involved with lazy reading and resolving be worth it? > Within this framework we can make things work as they do now, start to > optimise and support joins later. In fact I would prefer the opposite. I see the real need of joins today, whilst lazy loading still only fits in the " > I suspect the reality is we wont pay too badly for reading lots of stuff > because: > a) the implicit FeatureType is really a construct designed for playing > with the technology, not production services > b) you can always put a view into the persistence layer to optimise WMS > operations, where an implicit feature type is OK _provided_ you never, > ever, intend to support GetFeatureInfo for this layer. > c) we still get the pruning happening before the expensive bits - the > serialisation and network transfers > d) if it streams, let it go - we dont burn too much memory. > > This may not require any changes yet, but hopefully will inform any > changes planned. I agree with all the points above. But doesn't this mean all we need is to add join support and add complex data store to deal with different external views of our stored data? Cheers Andrea ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
