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

Reply via email to