Hi Martin,
Hmm, the problem is that we have multiple different meanings of 'approval' here. What you are thinking of is
- the object remains unmodified in the database until the completion of the process - a number of 'action/operation/transition/modification' entries are generated by each administrator - the desired transition is indicated in the 'action/operation...' entry ('approve', 'reject') - the object is modified once the required number of transition objects are available
I see some problems with this approach: There is no clear indication of how the object should be modified, because the transition type (approve, reject) is contained in each 'action/operation...' handle. Although it could be prevented by application logic, it is possible to create inconsistent data:
object - action/operation...(1) -> "Approve" action/operation...(1) -> "Reject"
What should we do now? The whole thing is ambiguos now, should we approve it or reject it?
I wanted to handle this with application logic but of course the design is not very safe.
I was implicitly thinking of the approach we had in this other project:
- object - administrator wants to change object, modifies it and writes it to another table of the database. let's call it the 'edit' state. by looking at the differences between the original object and the new one it is perfectly clear what action is going to be performed on the object - other administrators may acknowledge or reject this change - one single reject results in deletion of the changed object in the 'edit' state - a number of n acknowledge entries for the change object triggers promotion (copying) of the object in edit state to the original table, replacing the original object
This is how we did it in the other project. The approach is very clean but unfortunately not very easy to implement. (We also had some performance issues in a later stage, but this was because each and every object in the system had an 'edit' table that was used to hold modifications until the modification was approved by the required number of administrators. The performance problems began when multiple objects depending on each other were transferred between 'edit' and productive state.)
'edit' is only another state. So what about using serial and state as primary keys of the database table request. If this happens then we can put one request several times into the database.
new csr --> edit csr (new table entry) --> (editing stuff approved) new --> pending incl. changes from edit --> (csr fully approved) --> approved csr
During this process some others can start a recejection. --> reject csr (new table entry) --> (rejection approved by others) new --> deleted
Does this be the correct understanding of your idea? Perhaps another advantage is that conflicting processes (like editing and rejection) does not change the request with different goals at the same time (conflicting concurrency).
After the request is completed we will have only the final state and request in the database or do we want to have all states in the database (for auditing)?
If want to remember all old states then we must mark them as archived in some way without changing the data itself. Sounds like we should produce a graphical schema with state and database transitions.
Looks like I have today more questions than answers :)
Michael, Oli, how about a telephone conference about this issue?
Good idea, but I never do this before. So do you know how such conventional technology works ;)
I really think we have to get a clean design before we start messing things up...
Fully agreed.
Michael -- _______________________________________________________________
Michael Bell Humboldt-Universitaet zu Berlin
Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 [EMAIL PROTECTED] D-10099 Berlin _______________________________________________________________
------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ OpenCA-Devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/openca-devel
