Hi, >> requests that blocked others, but believe me, in field usage it pays >> to have a design that does not allow for inconsistent data. > how can one request block another?
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. > my understanding is, that they get handeled independet from each > other... i mean the aproval, since mass aproving makes no sense, > therefore are the operators wich have to review each request, if its not > pre authenticated, but then is the request review just at a other time > and at a another step in the processing of an request... (before the > request is inserted into openca) I think you are talking of different objects: yes of course it should be possible to have changes for different objects in edit state. >> And multiple contradicting edit entries *are* inconsistent. > the entries are only for this object - like in the 'edit' table, where > the votings get 'captured' and handled by application logic, and this > logic makes a dicission one time in the future, which leads to change of > the 'edit' state of the object... Sorry, I don't understand this. > (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. >> -> Optionally the system could generate notification emails once >> a request is in the queue that needs approval. > this we have somewher on the todo - so should be integrated anyway > this should be configurable: > - every new request triggers a information > - every n new requests triggers a information > - at least one information per day/houre/$timespan (if n is not > reached, so none gets 'lost' or a to high amount of time until > processed) Yup, sounds good. >> That way we should be able to do without the 'processed' flag, >> shouldn't we? > the processed flag has been just an idea for keeping knowledge about the > decission process, if someone wants to see it outside the audit-trail ;) Hmm, one reason for not introducing such a flag is that it is redundant information: you can get this information by querying the database. May be a join or some SQL function like count(), but the information is there. Redundandancy is bad for data consistence... > 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. Martin ------------------------------------------------------- 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