incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From couchdb user <>
Subject Re: Yet another transaction
Date Fri, 22 Oct 2010 12:49:21 GMT

see comments below:

On Fri, Oct 22, 2010 at 5:40 AM, Ido Ran <> wrote:
> Hi,
> I know tx question have been asked, but I never got a straight answer. I
> will present an example but I'm afraid that example distract us from the
> main issue which is "what is the new way of changing data?"
> Suppose I have CouchDB in which each document represent item in my
> warehouse. Each item has catalog number and quantity.
> I have agents who sale my items all over town, each agent has smart phone
> and internet access so they can use my great CouchApp :)
> One thing is very important - I don't want agent to sale item I don't have
> in stock and have all the items a client order.
> So one thing is for sure: We can't simply subtract the quantity client order
> from the item document because I might dead-lock myself.
> Client 1 order item Ax5, Bx3
> Client 2 order item Bx3, Ax10
> Suppose I have in stock Ax6, Bx3
> If I handle the two client order at the same time, first Client1 item A then
> Client 2 item B then Client 1 item B then Client 2 item A
> I will get to the last update of item A and find I don't have enough in
> stock, but there is no good way of rolling it back, let's say the buttery of
> the smartphone is dead I now took only half of the order.
> I can create a new document which will represent the order itself. It will
> have all the client detail as well as each item and quantity. Further I can
> create a validation function to allow only order which have all items in
> stock. Does it the way to go?
> Let's say I took the solution of order document, how do I actually process
> the orders and update the quantity of each item?
> I hope I made myself clear, I'm not looking to solve this specific problem
> but understand how to use CouchDB as non-transactional database.
> Thank you,
> Ido

How about moving the checks to the application level?

Your sales team uses something like a shopping cart, as they add items
to the cart, you check the stock of each item, if you have enough, go
ahead with the order, otherwise, return an error.

Those items do not deduct stock, because the order is in "created"
status. Once the sales rep. took all the items, he needs to
"checkout", at which point your application can check if you still
have enough of all those items, if true, the order goes to another
status, which will also mean you are deducting stock.

There may be some flaws with this design, but maybe it works just fine :)

Let me know if you have any questions.


View raw message