Hi Jody, Sorry I took too long to respond, I've took some days off to start fresh the new year ;)
On Friday 22 December 2006 22:24, Jody Garnett wrote: > Hi Gabriel, I have thought about both your feedback and Andrea's > feedback .. and I am kind of stuck. > > I respect what you are both asking for out of a Query object, but I am > worried about placing the implementation burden too high. I do like the > idea of a Query, but would be more comfortable if it was seperated from > this API. > > As example some needs are too hard for implementations to meet: sorting, > paged access etc... hmmm... I guess sorting should be one of the easiest features to implement? data is well backed by: - RDBMS: no problems, though you're tied to the usual existence of proper indexes tradeoff - Memory: shouldn't be that an overhead? a combination of Filter, Comparator and SortedMap? - Files - for shapefile would be tied to the existence or not of DBF indexes, for other kind of files who knows... - Service: WFS, CSW.. shouldn't be a problem as long as they also support sorting (wfs 1.1 and csw 2.0 does). Problem is the ones that don't I guess. So, what about a sorting flag as part of FilterCapabilities? > and some may be impossible (asking for a bean with > only some response elements filled in ). I guess most of the time if you're streaming pojos they'll come from some kind of OO storage (Hibernate, Jpox, etc) Actually, the possibility to ask for a pojo populated with a subset of their properties was vital for my implementation of csw. Lets see: csw defines some known subsets such as brief, summary and full. Since the implementation is based on the geotools iso metadata classes and hibernate, building a single metadata object could be quite expensive and require a bunch of sql queries. By the other hand, since the implementation is ntiered, it is not an option to keep the hibernate session open for the whole request life cycle (such as in the usual jface or struts + hibernate integration patterns), since that approach ties presentation logic to database. So we're actually returning the pojos initialized with a subset of their whole properties graph. That's just to say it is not impossible, but sometimes necessary. I could provide implementation details if they're of interest, but guess I should stop ranting about it and point out that I agree that we should find a balance with respect to Query, for which I feel the proposed api, as is, is by all means insufficient to be meaningful, and by the other hand I agree that QueryResults might be avoided, provided that we can find a way to tread paging. Thanks for all your help and patience :) Gabriel > So we can try it, but I really > need to focus on "easy of implementation" here, I want the library to be > useful to a wider community then what we are currently running. > > As it stands now I can dump a collection of any Pojo's onto a map, this > enables GeoTools to be used in many more situations then before. > > With respect to your Query API , I do like it and figure we will have to > sort out something along those lines. > Query Results however is a bit rough, see the wiki page for an alternative. > > Thanks again Gabriel - I am curious to what can be done here. > Jody > > >> ... > >> Oh, to be more clear, what I'm really concerned about is to have two > >> separated paths in the code for handling Source and FeatureSource, > >> this is what I find totally unacceptable. > >> > >> As for having the interfaces around with no duplicate code paths, > >> I'm not totally against, I still think they do add to the confusion > >> without provide any value, but at least they do not harm too much. > > > > Hi Andrea sorry about jumping on so late. I guess a revamp of the > > interfaces is indeed needed but not just to have one more level of > > abstraction but to actually add value as functionality. The current api > > is too "service oriented". Aka, purely streamlined, which is great, > > provided that we can support some common scenarios where one does not > > wants to go through the whole data. > > Example: paging and querying identifiers > > > > See my previous post with the link to the comment on the wiki. > > > > regards, > > > > Gabriel > > > >> 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=DEVDE > >>V _______________________________________________ > >> Geotools-devel mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/geotools-devel > > ------------------------------------------------------------------------- > 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 -- Gabriel Roldán ([EMAIL PROTECTED]) Axios Engineering (http://www.axios.es) Tel. +34 944 41 63 84 Fax. +34 944 41 64 90 ------------------------------------------------------------------------- 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
