[Geoserver-devel] GSIP 14 - WFS transaction handling framework

GeoServer GeoServer Developer
1

Hi all,
in order to make WFS-V work I had to create a tiny framework that allows
the transaction element processing to be open ended. This is already committed in trunk, and can be viewed as a Transaction class refactoring.

Yet, this calls for a more general framework in my opinion, so I have
taken the opportunity to expand its scope a little and came up with the
following GSIP:

http://docs.codehaus.org/display/GEOS/GSIP+14+-+WFS+Transaction+handling+framework

Please comment :slight_smile:
Cheers
Andrea

2

Andrea Aime wrote:

Hi all,
in order to make WFS-V work I had to create a tiny framework that allows
the transaction element processing to be open ended. This is already committed in trunk, and can be viewed as a Transaction class refactoring.

Yet, this calls for a more general framework in my opinion, so I have
taken the opportunity to expand its scope a little and came up with the
following GSIP:

http://docs.codehaus.org/display/GEOS/GSIP+14+-+WFS+Transaction+handling+framework

Please comment :slight_smile:

Nice work Andrea ...

For the TransactionEvent I think you are going to need leading edge / trailing edge notification (or at least document *where* the even is fired). Easy example is DELETE being fired before the event occurs. Also note that the event hooks needed for validation are well documented and include a case you missed. Integrity checks need to come at the end of the transaction "PRE_COMMIT" as it were.

The integrity tests actually need access to a map of all the data harmed over the course of the event ... a nice way to do that would be to:
1. break out different event types for each notification PreTransactionNotification, TransactionInsertNotification, TransactionUpdateNotification, TransactionPreDeleteNotification, TransactionPreCommitNotification, TransactionPostCommitNotification, TransactionPreRollbackNotification, TransactionPostRollbackNotification, PostTransactionNotification ... and define your listener with a method for each phase in the workflow (with appropriate data access for that stage of the workflow, example a FID set for a PreDelete).

This would let a single implementation collection some information (like say the bounds) during a PreDelete, and then that information in a PreCommit (perform an integrity check).

How much detail should we expect from proposals? For long term items like this one I am inclined for "more" even though I am very happy with the direction you are taking.

Cheers!
Jody

3

Jody Garnett ha scritto:

Andrea Aime wrote:

For the TransactionEvent I think you are going to need leading edge / trailing edge notification (or at least document *where* the even is fired). Easy example is DELETE being fired before the event occurs.

I stated it in the docs, but yeah, adding a flag to tell if the event
is trigger before or after the fact is useful.

Also note that the event hooks needed for validation are well documented and include a case you missed. Integrity checks need to come at the end of the transaction "PRE_COMMIT" as it were.

It's there, you missed it. TransactionPlugins has a:
void beforeCommit() throws WFSEXception
method that's designed exactly for that reason.

The integrity tests actually need access to a map of all the data harmed over the course of the event ... a nice way to do that would be to:
1. break out different event types for each notification PreTransactionNotification, TransactionInsertNotification, TransactionUpdateNotification, TransactionPreDeleteNotification, TransactionPreCommitNotification, TransactionPostCommitNotification, TransactionPreRollbackNotification, TransactionPostRollbackNotification, PostTransactionNotification ... and define your listener with a method for each phase in the workflow (with appropriate data access for that stage of the workflow, example a FID set for a PreDelete).

I agree we need to convey the meaning, but I'm not gonna add all
of these methods, they would make for ridicously long implementation classes. The first methods are covered by TransactionListener, I just need to add a before/after flag. Pre commit we do have, post commit and post rollback too. Pre rollback, it does not make sense in my opinion.

This would let a single implementation collection some information (like say the bounds) during a PreDelete, and then that information in a PreCommit (perform an integrity check).

Yup, that's how I wanted to re-insert back validation.

How much detail should we expect from proposals? For long term items like this one I am inclined for "more" even though I am very happy with the direction you are taking.

Tell me what do you need more. Motivations, design... on trunk you
can see an initial implementation too.

Cheers
Andrea

4

Andrea Aime wrote:

The integrity tests actually need access to a map of all the data harmed over the course of the event ... a nice way to do that would be to:
1. break out different event types for each notification PreTransactionNotification, TransactionInsertNotification, TransactionUpdateNotification, TransactionPreDeleteNotification, TransactionPreCommitNotification, TransactionPostCommitNotification, TransactionPreRollbackNotification, TransactionPostRollbackNotification, PostTransactionNotification ... and define your listener with a method for each phase in the workflow (with appropriate data access for that stage of the workflow, example a FID set for a PreDelete).

I agree we need to convey the meaning, but I'm not gonna add all
of these methods, they would make for ridicously long implementation classes. The first methods are covered by TransactionListener, I just need to add a before/after flag. Pre commit we do have, post commit and post rollback too. Pre rollback, it does not make sense in my opinion.

No worries could also do it with more constants (and your pre/post flag).

This would let a single implementation collection some information (like say the bounds) during a PreDelete, and then that information in a PreCommit (perform an integrity check).

Yup, that's how I wanted to re-insert back validation.

nifty.

How much detail should we expect from proposals? For long term items like this one I am inclined for "more" even though I am very happy with the direction you are taking.

Tell me what do you need more. Motivations, design... on trunk you can see an initial implementation too.

I am happy; I just wanted to know how much we expect. I usually like a picture but this one is pretty direct.

Cheers,
Jody

5

Jody Garnett ha scritto:

Tell me what do you need more. Motivations, design... on trunk you can see an initial implementation too.

I am happy; I just wanted to know how much we expect. I usually like a picture but this one is pretty direct.

Sigh, I agree with you, wanted to add a small class diagram.
I just have been disappointed by every tool
I tried so far. I'm looking for something that allows me to simply
draw a class diagram, without the detail needed to generate code,
but everything seems to fail glaringly... Poseidon you can't use anymore, argouml makes a pain to add attributes, omondo is heavy and
tries to pop up everywhere in my dev environment, umlet does not even have zoom or font setting, dia seems to be designed to make you waste time... bah! The nicer I ever used was smartdraw, but it's commercial and tied to windows, togheter community edition wasn't bad, besides being a mammooth, poseidon was totally unreliable, but not bad for
a throwaway diagram.

End of rant :frowning:

Cheers
Andrea

6

Jody Garnett ha scritto:

Andrea Aime wrote:

Tell me what do you need more. Motivations, design... on trunk you can see an initial implementation too.

I am happy; I just wanted to know how much we expect. I usually like a picture but this one is pretty direct.

So, I incorporated the enumeration of possible changes (as a list of ints, since we don't have java5), simplified the transaction listener interface as a result, and added a class diagram (made with Jude community edition, not that bad, not freestyle, but at least they added keyboard shortcuts to add attributes and methods relatively quickly).

Cheers
Andrea

7

Thanks Andrea - a class diagram makes me actually trust that your proposal is looked at (I did not understand Justins last proposal until I went over the class diagram with Jesse).

Note you can use the GeoAPI code list as a "enum" replacement if you like. I actually like the result better and it is method compatible with Java 5 enum.

Cheers,
Jody

Andrea Aime wrote:

So, I incorporated the enumeration of possible changes (as a list of ints, since we don't have java5), simplified the transaction listener interface as a result, and added a class diagram (made with Jude community edition, not that bad, not freestyle, but at least they added keyboard shortcuts to add attributes and methods relatively quickly).

Cheers
Andrea