[Geoserver-devel] Rollback with spatial filters, no so trivial...

GeoServer GeoServer Developer
1

Hi all,
I'm having some issues with the semantics of a rollback
in the versioned data store, so I'm going to describe
the problem to see if anybody has some clue.

I was thinking of adding the following operation to the
versioned datastore:

void rollback(String version, String typeName, Filter filter, Transaction t);

where:
* version is the revision, or could be branch:revision
   once we have the
* typeName is the feature type subject to rollback
* filter matches the features that need to be rolled back
* transaction allows to do multiple rollbacks on different
   feature types and carries user and commit message as properties

Now, my problem is the filter... what should the filter match?
The old features, the current ones?
That's not trivial, think about a bbox filter, and a feature
that moved from inside to outside the bbox. Shall I rollback it?
And what about features that were deleted? They have no
current state.
What about the ones that have been created? They have no old state.

So, I'm lending to apply rollback to every feature that matches
the filter in either the new or old state, but I'd like to hear
some feedback about this before going on.

Plus, there's a limitation. What if I wanted to rollback only things
that a silly user did? Unfortunately userid is not part of the
feature type, so it's hard to deal with it. Maybe the method should
be:

void rollback(String version, String typename, String userId, Filter filter, Transaction t).

Opinions?
Cheers
Andrea

2

On Wed, 2006-12-20 at 19:14 +0100, Andrea Aime wrote:

Hi all,
I'm having some issues with the semantics of a rollback
in the versioned data store, so I'm going to describe
the problem to see if anybody has some clue.

I was thinking of adding the following operation to the
versioned datastore:

void rollback(String version, String typeName, Filter filter,
Transaction t);

where:
* version is the revision, or could be branch:revision
   once we have the
* typeName is the feature type subject to rollback
* filter matches the features that need to be rolled back
* transaction allows to do multiple rollbacks on different
   feature types and carries user and commit message as properties

Seems like you are doing something much more complex than a simple
rollback.

At the start of any 'rollback' transaction, the system can generate the
trio:
        (past state, diff to current state, current state).

If I understand you right, you want to get 'new state' using:
        (past state, alternative diff to current state).

so semantically your operation is against the diff not either of the end
states.

Not sure what that implies, but I suspect that all of the conflicting
operations, like those you describe, arise because you can't
semantically use the start and end states to describe the diff of the
diff.

--adrian

Now, my problem is the filter... what should the filter match?
The old features, the current ones?
That's not trivial, think about a bbox filter, and a feature
that moved from inside to outside the bbox. Shall I rollback it?
And what about features that were deleted? They have no
current state.
What about the ones that have been created? They have no old state.

So, I'm lending to apply rollback to every feature that matches
the filter in either the new or old state, but I'd like to hear
some feedback about this before going on.

Plus, there's a limitation. What if I wanted to rollback only things
that a silly user did? Unfortunately userid is not part of the
feature type, so it's hard to deal with it. Maybe the method should
be:

void rollback(String version, String typename, String userId, Filter
filter, Transaction t).

Opinions?
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=DEVDEV
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

3

Adrian Custer ha scritto:

On Wed, 2006-12-20 at 19:14 +0100, Andrea Aime wrote:

Hi all,
I'm having some issues with the semantics of a rollback
in the versioned data store, so I'm going to describe
the problem to see if anybody has some clue.

I was thinking of adding the following operation to the
versioned datastore:

void rollback(String version, String typeName, Filter filter, Transaction t);

where:
* version is the revision, or could be branch:revision
   once we have the
* typeName is the feature type subject to rollback
* filter matches the features that need to be rolled back
* transaction allows to do multiple rollbacks on different
   feature types and carries user and commit message as properties

Seems like you are doing something much more complex than a simple
rollback.

At the start of any 'rollback' transaction, the system can generate the
trio:
        (past state, diff to current state, current state).

Of course I can, but it does not seem practical to me to treat the versioned datastore contents as a whole when rolling back. Oh, consider
each transaction generates a new revision, and each revision can reference modifications in multiple feature types (so treating things
as a whole would mean rolling back all the tables back to revision x).

If I understand you right, you want to get 'new state' using: (past state, alternative diff to current state).

so semantically your operation is against the diff not either of the end
states.

Not sure what that implies, but I suspect that all of the conflicting
operations, like those you describe, arise because you can't
semantically use the start and end states to describe the diff of the
diff.

I'm considering a situation where multiple people edit data at the same
time, for the sake of simplicity lets consider a single feature type.
For some reason edits in a particular area are screwed up, but not those
in others. Bad edits date back to revision r.
Without filters, I would have to roll back everything up to r, and then
somehow find the good edits and reapply them. Or I can do what I suggest
above, filter in the rollback operation and avoid rolling back the good edits.

With svn you really do that all them time, you choose a file out of the
whole tree and do a back-svn-merge to restore it to a previous state.
You did not rollback the whole tree, you really "filtered" your rollback
to a specific subset of data.
In our Filter API terms, this is a kind of FID filter.
If I was to rollback a folder with its contents, it would be kinda like
a bbox filter (it's the closest thing to containment we do have). This
makes me wonder, what happens in svn if I do move a file out of folder1 into folder2, and then do a "svn merge -r n:n-1" only on folder2... what
happens? I'll try this one out.

Cheers
Andrea

4

Andrea Aime ha scritto:

Adrian Custer ha scritto:

If I was to rollback a folder with its contents, it would be kinda like
a bbox filter (it's the closest thing to containment we do have). This
makes me wonder, what happens in svn if I do move a file out of folder1 into folder2, and then do a "svn merge -r n:n-1" only on folder2... what
happens? I'll try this one out.

Well, fact is svn can provide a full history of what is inside a folder
and as you said has a series of diffs for that.

Too bad I don't have "containment" concept, so to replicate the same
behaviour as svn I would have to avoid filters altogheter, which is not
practical.
I should try to perform the rollback on whatever matched
the filter in any revision between current and old one, this should
give me a semantic close to svn I guess.
Thought I don't know if this matches well the intententions of a
data manager trying to roll back a part of a map that has been improperly changed. This person would have to see what features are
affectet in a visual diff and probably refine the filter to match
exactly what he wants...

Cheers
Andrea

5

On Thursday 21 December 2006 12:30, Andrea Aime wrote:

Andrea Aime ha scritto:
> Adrian Custer ha scritto:
>
> If I was to rollback a folder with its contents, it would be kinda like
> a bbox filter (it's the closest thing to containment we do have). This
> makes me wonder, what happens in svn if I do move a file out of folder1
> into folder2, and then do a "svn merge -r n:n-1" only on folder2... what
> happens? I'll try this one out.

I bet you'll get file removed from folder2, which by no means implies it is
put back on folder1.
afaik a svn merge acts as a shortcut for diff+patch, so there isn't actually
any rolling back. I'm a bit confused about the terminology being used here
though. Thought rollback would be one of the ending actions of a single
transaction, but you're calling rollback a new transaction which acts as the
counter-transaction of another one?

excuse the rant

Gabriel

Well, fact is svn can provide a full history of what is inside a folder
and as you said has a series of diffs for that.

Too bad I don't have "containment" concept, so to replicate the same
behaviour as svn I would have to avoid filters altogheter, which is not
practical.
I should try to perform the rollback on whatever matched
the filter in any revision between current and old one, this should
give me a semantic close to svn I guess.
Thought I don't know if this matches well the intententions of a
data manager trying to roll back a part of a map that has been
improperly changed. This person would have to see what features are
affectet in a visual diff and probably refine the filter to match
exactly what he wants...

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=DEVDEV
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

--
Gabriel Roldán (groldan@anonymised.com)
Axios Engineering (http://www.axios.es)
Tel. +34 944 41 63 84
Fax. +34 944 41 64 90

6

Hey Andrea,

First of all, your work has me very excited---it seems like an effort
that will raise the bar substantially on the utility of Geotools. So
thanks for your work.

Secondly, I'm saying something really small and unrelated to any
implementation question. You raise a scenario of filtering against
initial state or end state and show that it leads to problems. All I am
saying is "your scenario leads to problems because logically you have to
filter against the changeset rather than against the start/ end states"

I think, without any deep thought or analysis, that my statement is
correct and resolves, logically, the problems you raise. I do not know
nearly enough to help you on the implementation side.

cheers,
adrian

7

Gabriel Roldán ha scritto:

On Thursday 21 December 2006 12:30, Andrea Aime wrote:

Andrea Aime ha scritto:

Adrian Custer ha scritto:

If I was to rollback a folder with its contents, it would be kinda like
a bbox filter (it's the closest thing to containment we do have). This
makes me wonder, what happens in svn if I do move a file out of folder1
into folder2, and then do a "svn merge -r n:n-1" only on folder2... what
happens? I'll try this one out.

I bet you'll get file removed from folder2, which by no means implies it is put back on folder1.
afaik a svn merge acts as a shortcut for diff+patch, so there isn't actually any rolling back.

Indeed.

I'm a bit confused about the terminology being used here though. Thought rollback would be one of the ending actions of a single transaction, but you're calling rollback a new transaction which acts as the counter-transaction of another one?

Of multiple ones in fact yes. The idea is that I want to go back to the state at revision x for features that match a filter, and I want to do so by applying a new transaction that reverts whatever was done between
revision x+1 and current (which means, remove new features, reinstate
deleted ones and get back the state of those that are still there to
the one at revision x).

Cheers
Andrea

8

Adrian Custer ha scritto:

Hey Andrea,

First of all, your work has me very excited---it seems like an effort
that will raise the bar substantially on the utility of Geotools. So
thanks for your work.

Secondly, I'm saying something really small and unrelated to any
implementation question. You raise a scenario of filtering against
initial state or end state and show that it leads to problems. All I am
saying is "your scenario leads to problems because logically you have to
filter against the changeset rather than against the start/ end states"

Yes, good point, and may be what I'm doing, or not, depending on semantics.
What I'm doing is taking each feature that changed between revision m and n, and saying it matches the filter if at least one state of the
feature between m and n matches the filter.
So, if I say filter against a certain bbox, I will say the a feature
matches the filter if it has changed between m and n and at least one
of its revisions stayed inside the bbox.
Or maybe all, I mean, if the feature never moved, stayed in the bbox
all time, but some other attributes changed, I will match it as well.
This is consistent with someone asking to rollback every change that
occurred in the area matched by the bbox.

Is it what you intended?

Cheers
Andrea