couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Metin Akat <>
Subject Re: FIFO/LIFO accountancy
Date Wed, 03 Feb 2010 18:50:31 GMT
On Wed, Feb 3, 2010 at 8:13 PM, Andrew Melo <> wrote:
> What happens to the customer then? You've shown me a page saying
> "order complete" and then at some point down the line (whenever
> couchDB notices the probem or your state machine catches up on
> _changes), it realizes it can't fulfill the order. Even worse, all of
> the cheaper apples are actually gone, and all that's left are the more
> expensive ones.
> I think your better bet would be to use something that was aware of
> atomic commits handle the inventory-ing, and then export that data
> couch to run map/reduce over, rather than hoping to enforce atomic
> semantics on what is an unatomic subsystem.
> Best,
> Andrew

Hi Andrew,
There are no such problems in practice. I'll explain you why:

1. In the case of a big corporate purchase (often an import from
another country), such processes happen over  big periods of time
(days or weeks) and not seconds (the time required for couchdb to
process updates). In the case of insufficient apples, there is often
enough time to buy more apples from our suppliers, not to mention the
possibility to delay the confirmation with several minutes (or even
hours) before sending it to the customer. This is true for online
purchases as well.

2. In the case of an end user purchase (supermarket), there is no
chance that the cashier will issue a document of purchase for apples
that are not on stock. The fact that you as a customer hold the apples
in your hand ensures that they are on stock (unless there is some big
error, which is not what we are talking about).

3. The problem with the price (only the expensive apples are on stock)
is not a problem too. In real world differences between batches are
not so extreme. Most of the time they are even at the same price. And
even when they are not, this does not require new price to be put on
them. It only slightly modulates the end profit of the company. And
even if that would be a problem, it's a problem of management and
price making, not a problem of the software. For software, it's OK if
we realize loss on sales (one of its functions is to warn on such

4. And even in the extremely rare case when this kind of a problem is
really a problem, the legal system has its mechanisms of resolving it.
There are special kinds of official documents that are "supplements"
to previously issued invoices. Their purpose is to resolve such
problems of different origin. It's probably quite a common situation
such a problem to arise from errors in input data. Then, although the
software system calculates correctly, at one point there are not
enough apples on stock. This are "normal" situations in real life and
we have the needed tools to resolve them.

View raw message