Martin Bartosch wrote:
but thats what i mean in seperating the 'change' from the object and its state itself:admin 1 requests operation X on object A -> results in an entry in edit state
Now as long as the request is neither approved nor revoked it is not possible (it SHOULD not be possible) to add a new (conflicting) change request for the same object. That would mean two active change requests whose implications on the object might be contradictory.
object enters state edit (through whatever action ever, in our case the first operator starting the decission process) this is consitent for the object - it enters state edit - like new, approved, rejeceted, and so on and stays there till something happens that enables it to leave this state
the change process then is handled by its own, and there will be a result - either the object changes to approved or to rejected
the object can only leave the edit-state if the decission making process gets to an solution (however this happens inside this process, doesn't interest the object and its state, it just 'cares' for the result)
and the decission making process is already described in detail i think: - there is a setup: n operator approves are needed to get the approve for the object - n is set for each openca instance, default is: 1 - if a new decission by an operator arrives the decission process looks if its approve or reject and if n is reached - if reject -> decission=reject -> object changes state to rejected remove decission data (separated table) - if approve and n reached -> decission=approved -> object changes state to approved remove decission data (separated table) - if approve and n not reached -> do nothing
so the object is always in consistent state, the decission process for this object too - at least in my point of view ;), and in a different reality this decission making process could look different, but why not
but this still doesn't solves my other question:
which signature does the object get afterwards the decission is made?
when it is approved - since it won't be an operator signatur or when, which one of them? - would there then be an abritrary 'ra-key' which signs the approved request?
(actually this could handled soly by the database logic, but not all support this, so in the end our application logic has to do it... otherwise one could do this with triggers and db-scripting quite nice, but this is no option fur us i think)My recommendation would be: - no triggers - no database scripting Yes, it does hurt performance, but it greatly increases portability.
ack
i know - that was also the thing i mentioned about old states of requests or objects, you can get this through the audit trail if needed, i didn't wanted application logic accessing it, but i wanted to keep all of us in mind, we don't have to keep some things in the database, since they should be already in the audit trail... and usaly you don't need this information in further processing (like old states of the object, maybe the last one before the actual one, which could simply reached by an column previewsState - but i think, we don't need this anyway)so the entries in the 'edit' table doens't get deleted, but 'ignored' since this object has been processed (not in state 'edit' anymore, an object is only alowed to leave state 'edit' if the 'edit' table is either clear of entries of it, or all entries are marked 'processed')As I said, I am in favour of not keeping "historical" data in the DB. You can always reconstruct the modifications via the audit trail if need should be.
so we don't need it, we don't talk any longer about it...
eot for this part i think
greetings dalini
------------------------------------------------------- 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
