Re: [Geotools-devel] isGeometry() committed, datasource question. [was: adding isGeometryPosition in FeatureType interface?]

[Chris H. <ch...@op...>]

> > So maybe that should be how we split up the interface?  A normal
> > (abstract?) datasource will just have getFeatures and whatnot, a 
> > FileDataSource will have setFeatures, and a TransactionalDataSource will 
> > have add, remove, update, startMulti and endMulti?  And then a 
> > Transactional Decorator, to turn FileDataSources into 
> > TransactionalDatasource?  
> 
> Yes, this way you get the basic datasource capabilities just by means of a bunch
> of instanceof tests. But I'm not sure about the FileDataSource interface, having
> a getFeatures and setFeatures as the methods I wonder where the "file" is...I see
> better something like DataSource <-- WritableDataSource <-- TransactionalDataSource,
> but it's suboptimal too, a data source could have add/modify/delete without supporting
> transactions... what if the DataSource has all of the methods plus Start and Stop multi,
> then in the Metadata one can query what kind of operation is really supported?
That could be good.  Actually, yeah, I like that a lot.  What do other 
people think?  Andrea, are you going to make the irc?  It's in 2 hours, 
and would be a great chance to work this stuff out and go forth with it.

> >> Another variant would not to keep data in memory but to keep a list of the 
> >> operation performed on the data source, when a getFeatures is performed we
> >> load data from the real data source, replay the operation and provide results,
> >> when the transaction ends we load all of the data, replay operations and
> >> call setFeatures on the resulting feature collection (I think we already spoke
> >> about it, but not remember with who and when...).
> > Right, I remember that.  And I think you'd actually sometimes _not_ replay 
> > the operation when returning getFeatures, in the case when startMulti has 
> > been called.  In that case you don't want your modifications to go through 
> > until after endMulti is called...in the meantime you just return the 
> > getFeatures from disk.  I'm not sure that I really like the startMulti and 
> > endMulti naming, but I can't think of anything much better.  There's the 
> > jdbc way - setAutoCommit(false), and then call commit() when done.  Or sql 
> > - start and end.
> 
> Uhm... not. With jdbc when you start a transaction you actually see the modified
> data in the connection that started the transactino, not the old ones,
> but other users don't see the modifications until you commit, AFAIK, which
> is consistent with the replay scheme I think.
Oh right.  I was thinking of other users accessing getFeatures.  So in 
your scheme only the user who puts the transaction decorator on would use 
getFeatures that way.  That makes sense, and I think I can get that to 
work with my needs.

> >> When you speak about locking, do you mean table lock, or single feature lock?
> >> The first is quite easy to do on a file based data source, but the second may
> >> be a bit more difficult.
> > I mean single feature locking.  Yeah, it's not the most fun problem, but 
> > it's what I need to do.  I've been thinking through it, and I can write it 
> > up if anyone would like.  Basically you need a layer that knows what 
> > features are locked which forwards things on appropriately, checking the 
> > locks on the way.
> 
> Yes, I would like to hear about it. What if multiple application are working
> on the same database? If you don't keep lock in the database itself, how
> can you prevent another application (in another VM, or a native application
> as well) to modify the features?
I'll address that in another email, to break these threads up a bit.  But 
the short answer is that I'm working from a wfs perspective, so I just 
have to worry about locking from other wfs transaction requests, not from 
everyone in the world who might access it.  What you say might be good 
reason for me to put the locking code in geoserver and not in geotools.  
But I'll write up my thoughts thus far on locking sometime soon, as I'd 
like geotools people to have a look at it, see if we can put things in 
geotools.

> > Also, does all of this fit with gmldatasource, since that's our other main 
> > datasource?  It's file based, so I guess most of the shapefile stuff 
> > applies, yes?  Rob and Ian?  Also, have we had any thought about a toGML() 
> > method for features and featureCollections?  It would make things easier 
> > for setFeatures for the gml datasource.  Geoserver has a GMLBuilder class 
> > that builds gml from features, but it would be nice to just be able to 
> > have it all print itself.
> 
> Uhm... not sure about it... I think I'd prefer the ability to call setFeatures
> on a GMLData source that happens to work on a ByteOutputStream, or something
> similar, and the get the string form the stream afterwards. This way only the
> GML data sources knows how to read and build GML, and if you don't need GML
> you wont' get useless code in your jars (think about applets or other small
> applications). Just my opinion...
That makes sense.  I don't feel strongly about this at all.




Chris