Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
So I've had some time to think about the datasource interface, as I said
I'd code up a sample request object to use with the getFeature method of
the datasource interface.
But first, two small proposals for the datasource interface:
1. getBBox to throw a DataSourceException. IanS mentioned this in his
exceptions emails. And did we ever decide what to do about exceptions?
Perhaps we should discuss more at the next IRC, decide on a course of
2. This is actually for the metadata interface. I'd like to split
supportsTransaction into supportsAdd supportsModify and supportsRemove.
If anyone likes I could leave supportsTransactions in, and it could just
return the boolean AND of those three. But I think that'd probably just
As for a request object, I've coded up Query interface, my first ideas of
what that object would look like. It's based on the WFS Query, with a
slight modification (added maxFeatures). Most of the javadoc comments are
out of the WFS specification. The comments below the javadoc ones are
mine, about the reasons for the methods, how they fit in. So reading the
source should explain most of my thoughts.
As for the reasons for moving to the request object, I think it allows the
getFeature method to be a lot more flexible. Instead of making an
interface change every time we might want to add a new parameter to
getFeature, we can just change the query object. The parameter list is
short right now, but that's more because I hacked much of what I
originally needed out of the datasource into constructors and postgis
methods. Out of that came the get and setSchema, as a way to get specific
properties out of the datasource, but I think the propertyNames portion of
the query object is much more intuitive than forcing are users to
understand FeatureTypes and how to create new ones just to get out the
porperties that they want. The query object also more closely mirrors the
wfs way of doing things, so anyone coming to the toolkit with that
knowledge will have a much easier time understanding what's going on. So
if we are to not decide on the query object, I'd like to change the
DataSource interface to have a propertyNames parameter. I guess I could
do without the maxFeatures with the iterator, but I think there are a few
reasons to provide maxFeatures in addition to the iterator. Also, a
typeName param should probably be used, unless we want to always constrain
ourselves to one featuretype per datasource. With those the param list
gets pretty long, so I think the query object is the best route. It also
allows us to easily support feature versioning if and when we move in that
direction, since that would have to be another parameter for getFeatures.
The other nice little feature of the query object is that we can also
borrow the 'handle' element, a string to identify the object that was
being serviced when something went wrong.
There are a few questions, and looking at comments in the source is the
best way to read the issues. So if you all could just look at the source
and reply to questions raised there that'd be great.