[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: Preventing double-updates
- Subject: Re: RFC: Preventing double-updates
- From: "Chris Travers" <..hidden..>
- Date: Fri, 13 Jul 2007 10:29:41 -0700
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