couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Melo <>
Subject Re: FIFO/LIFO accountancy
Date Wed, 03 Feb 2010 19:04:27 GMT
On Wed, Feb 3, 2010 at 12:50 PM, Metin Akat <> wrote:
> 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
> events).
> 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.

Sounds like you have a pretty unique use case where you want to keep
track of inventory, their prices and your current balance, but at the
end of the day, you can just approximate all of them and manually
intervene if something goes awry. I didn't gather that from the
initial email you sent out. It sounds like the benefit of being able
to map/reduce on the same database that's keeping track of your
numbers and enforcing the rules outweighs the cost of having to
manually track out weird edge cases when your project becomes more
successful, if you're working in large enough chunks that you can
assume your conflict rate is going to be low.


Andrew Melo

View raw message