[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: Preventing double-updates



Actually, I would think a row-level trigger would be more appropriate.

Not possible in 1.3 unless we also decide to just scrap that release
and go straight to 2.0.

The reason is, a single check hits a surprising number of rows in one
table in the codebase we have inherited.  I expect this to change in
1.4, as it is on our todo list and is just something we haven't had a
chance to address yet.  Checks have a many<->many relationship with
invoices and there is no authoritative place to store that data in a
normalized fashion.

Note that this may change in 1.4 because we are likely to have a
database structure more condusive to db-controlled solutions.
However, at the moment, there is no way to implement any row-level
rules regarding check printing.

However, this poses another problem which is why session-level rules
may still be necessary.

Suppose 2 people start a check printing process.  They don't know
eachother is doing it.  The web app is stateless so we have no way of
doing proper transaction processing across requests.

Person 1 pulls a list of vendors that need to be paid and applies the payments.
Person 2 pulls the same list of vendors and applies the same payments.
Person 1 prints and posts the payments
Person 2 tries to print and post the payments and gets an error.

If person 2 had been informed of the possibility that person 1 was
actually using the data at the beginning, less time/productivity would
have been wasted.

Best Wishes,
Chris Travers