Take a Look at feature versioning
---------------------------------
Key: GEOS-358
URL: http://jira.codehaus.org/browse/GEOS-358
Project: GeoServer
Type: New Feature
Reporter: dblasby
Assigned to: dblasby
Fix For: 1.3.1
FeatureVersioning for Features affected by Transactions.
Here's a message from the mailing list, see the rest "[Geoserver-devel] WFS xforming" and "[Geoserver-devel] Re: WFS xforming".
You recently mentioned (in the context of wiki-like-editing spatial
data) of having the WFS keep track of feature updates and deletes (ie.
keep some sort of historical information) so that it could be either
'rolled back' or you could ask for a view at a particular timeframe.
I was thinking this could be done with a simple web service that would
take an incoming WFS <transaction> and transform it into a more complex
set of sub-actions.
For example, an update could move the current database row to another
table (with a timestamp), then update the actual row. These operations
can be easily expressed in terms of other WFS request. In the above
case, the update request gets translated into a GetFeature (from the
main table), Insert (back up that row in another table), then an Update
(of the main table). If you were really paranoid, you can also throw
in some locks!
There's all sorts of different ways of keeping historical information.
To the outside world, they only see a normal WFS-T so clients dont have
to even know that something fancy is going on, which is super sweet for
application developers.
I also think this (having a meta-service wrap a more basic service in a
chain) is a good way of doing the current validation instead of where
its currently performed (but I could be convinced otherwise on this).
The above request Xforms could be done with an XST, so it could actually
be extreamly simple to put together. The main problem would be that
you might need some type of two-phase commit to handle the case in
which one of the sub-steps fail because I dont think you can have a
single transaction on a set of featuretypes (and the backup table/main
table would almost certainly be two featuretypes). This is a solvable
problem.
What do you think?
David Blasby
-----------------------------------------------------
Very much agree, I was thinking many of the same thoughts when I wrote
this: http://lists.eogeo.org/pipermail/opensdi/2005-April/000076.html
But it ended up as more of a brain dump.
I think expressing the insert stuff as another set of WFS-T operations
is definitely key. I like your thought of doing it as normal WFS-T
transaction, and then just performing the sub actions. Indeed the nice
thing is that the second table of the history stuff is _also_ available
as WFS, and could be used by clients to return the revision history.
I very much agree with you re: doing validation there, instead of where
it's lumped in now. Indeed I think eventually it would be great if a
user could 'compose' their insert chain. You could introduce other
things into the work flow like a peer review. Before the real commit
it goes to another temp table where someone else has to review the
changes and sign them off before it modifies the main. Validation,
attribution, peer review, revision history, and more would just be
options that a user chooses for how much process they want in their
spatial data maintenance. And yes, for application developers all that
should be exposed is WFS-T.
The one thing we really need though, that is currently missing, is
attribution. In a hacky approach I was thinking of doing a first run
with a _slightly_ different WFS-T request that had a field for
'username'. Eventually (or perhaps sooner) we could do authentication,
which would be nice for security reasons anyway. Even if we allowed
everyone to sign up for an account...
The one other thing that I feel would be nice to have is a 'comment'
field, like in cvs commits, so you can see why someone did a given
change, what their source for the change was, ect.
Though I suppose that you could make it a special attribute in Features
inserted. Though that's hacky. Or do we have the possibility of
vendor specific params in WFS-T?
I'm not 100% sure but I think that our current transaction architecture
does not commit until all inserts are successful, I believe even cross
datastores. Like if your second or third sub transaction fails then
all rollback. So as long as they're in the same end transaction
request (which can hold inserts and updates mixed) then it should be
fine.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira