Shapefile provider update

Coordinator
Aug 31, 2006 at 6:44 PM
I'm updating the Shapefile provider to allow updating (writing to) shapefiles. The thing I've come up against is the concept of a shapefile being "open" (IsOpen == true).

The issue is that the state is not checked during a number of operations (in the current checked-in version of Shapefile.cs) which require it to be open. I've been adding documentation and state-checking to improve the robustness of the provider, and am not exactly clear when an exception should be thrown if the shapefile is not open. Some operations are obvious, but others, like getting the ShapeType or the Coordinate System, are more fuzzy.

What I would currently like to do is to make the provider throw an exception when it is not open for all operations other than getting/setting the Filename or ConnectionID properties, getting the IsOpen property and calling Open (of course!). This would more closely match a database-oriented connection, where you can't get any information about the data until you open the connection.

This is a behavioral change which would require some modifications to SharpMap code, and would break any clients of the Shapefile provider which don't open the connection first.

Thoughts?
Developer
Aug 31, 2006 at 10:19 PM
Properties like shapetype and coordinatesystem are read during initialization. Since these are already available, why prevent someone from accessing them without opening and closing the datasource? Opening and closing do impose some extra overhead.
When the layer is rendered, it is not opened unless the envelope is inside the current view. Thus if you can't access the Envelope and coordinatesystem without opening it, you would brake the code.
Coordinator
Aug 31, 2006 at 10:52 PM
Good info -

Suppose SRID/CoordinateSystem and Envelope are added to the list of "available without opening". Everything else throws an exception. This shouldn't break SharpMap as it is currently. How does that sound?
Coordinator
Aug 31, 2006 at 10:54 PM
Also -

What are the thoughts on doing connection pooling with the Shapefile provider? This could change the questions considerably...
Developer
Sep 1, 2006 at 8:13 AM
I think this is a good idea. Feel free to add those exceptions.

Regarding connection pooling I've been looking into that for quite a while. It can be done once-and-for-all on all the connections, and not the shapefile provider alone. If you download the source for NPGSQL there are some good examples on how this can be accomplished. The ConnectionID property is actually meant for later implementation of connectionpooling. This identifies the datasource uniquely (ie. shape-filename or connectionstring)