Hi, >> 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.
yes, this is a good solution. Of course this depends on the fact that the object id is not unique by itself, but only the object id and state tuple. (No problem for decent databases, but one has to be careful when writing SQL statements that access this data, inclusion of the desired state is required...) > 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 This is one of the major drawbacks of the approach. Using the (id, state) tuple as primary key it is possible to hold an entry for each possible state in edit state. This may lead to conflicting information. The example above is one of these conditions. The approach with a separate table is less performant but inherently prevents inconsistent data by only allowing one object in edit state at any given time. Considering your example: one admin has to reject the first change request in edit state first in order to insert a fresh one with a different target state. > 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). Perhaps I don't understand you correctly. Are you saying that it is OK to have multiple entries with conflicting target states? > 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)? The audit trail should still record any change of any object, but there should only be the currently active (plus any pending changes in edit state) in the DB. > 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. As I said, I don't think it's a good idea to have all the old data lurking around in the DB. Schema and stuff sounds like a good idea. Wiki, anyone...? :-) I think MoinMoin also supports online drawing of diagrams. Might be useful and productive that way, but that's just an idea. > Looks like I have today more questions than answers :) Yes, one of those days... >> 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 ;) Michael, does there happen to be a funny looking plastic thingy on your desk that sometimes makes some irritating noise and after a while stops...? :-) 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
