From user-return-8680-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Wed Feb 03 18:51:01 2010
Return-Path:
Delivered-To: apmail-couchdb-user-archive@www.apache.org
Received: (qmail 73035 invoked from network); 3 Feb 2010 18:51:01 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
by minotaur.apache.org with SMTP; 3 Feb 2010 18:51:01 -0000
Received: (qmail 91398 invoked by uid 500); 3 Feb 2010 18:51:00 -0000
Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org
Received: (qmail 91340 invoked by uid 500); 3 Feb 2010 18:51:00 -0000
Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: user@couchdb.apache.org
Delivered-To: mailing list user@couchdb.apache.org
Received: (qmail 91329 invoked by uid 99); 3 Feb 2010 18:51:00 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Feb 2010 18:51:00 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of akat.metin@gmail.com designates 209.85.219.213 as permitted sender)
Received: from [209.85.219.213] (HELO mail-ew0-f213.google.com) (209.85.219.213)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Feb 2010 18:50:51 +0000
Received: by ewy5 with SMTP id 5so1753234ewy.32
for ; Wed, 03 Feb 2010 10:50:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:received:in-reply-to:references
:date:message-id:subject:from:to:content-type;
bh=49b7u36IpaiSGrmTuFW4YPSwWSC6w+zpHz6PDXw6Gds=;
b=WSGE1LqCqliPC6iX7eZI0Fuh+UYdfPC5Xg8kwvLLmrusznJIPMGcYNUTRSDVJOtCQi
zg20IA5MGvbZXK/yhd5Su8SzDaNY58pm4x8muT7H0A3jIqawHZlI9yontk0q/Cy6WWDy
wQqqDgepIcuBO76mCdWgUkgUbeKWYilFPphhQ=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
b=EP9ydU9oaqU9pVH3RBOvNhaGQEVKlQ77vNE0IoQ8yRO8Zlerhu85u7NXyJ6nOMlihR
GPOnmrgJ8DCr8Zg2fSZh+OZDahwHlrsECVLMCJJvqd7gN5fA/cjYquApQXbeS2/jVmtp
sePCA46sgjqvfr0OwTVF6dCqd/yUccPihcAcU=
MIME-Version: 1.0
Received: by 10.213.40.194 with SMTP id l2mr1943835ebe.92.1265223031104; Wed,
03 Feb 2010 10:50:31 -0800 (PST)
In-Reply-To:
References: <98a246a11002030729v51edbb91yd39f41f3e96c8f6e@mail.gmail.com>
<20100203163741.GA9508@uk.tiscali.com>
<98a246a11002031007o998a242ta015fd3ac87df3c8@mail.gmail.com>
Date: Wed, 3 Feb 2010 20:50:31 +0200
Message-ID: <98a246a11002031050y34617df1t13406e1b1f8492e7@mail.gmail.com>
Subject: Re: FIFO/LIFO accountancy
From: Metin Akat
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
X-Virus-Checked: Checked by ClamAV on apache.org
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.