advice on placing items into cart and quantities

[Phil Powell]

You have ordered one item and placed it into your cart. Let's say you
ordered one small black t-shirt. Your cart will have the product_id,
color_id and size_id for the small black t-shirt. The quantity of this item
is, let's say 30. You have one in your cart, so how many are available:

1) 29
2) 30

Now let's say that while I ordered one small black t-shirt, Sven ordered 1
small black t-shirt, Anders ordered one black t-shirt, and Olov ordered one
black t-shirt. If all four of us, at one time, are all ordering the same
item and putting it into our carts, how many should there be available to
us:

1) 26
2) 25
3) 29
4) 30

This is where the contention comes in. The client wants it done "FIFO"
(First In First Out) meaning that whoever gets it first will subtract the
quantity - but I dispute that (coming from somewhat of a Java background)
that since PHP doesn't so single-threading, that means that all four of us
could order t-shirts, but the quantity has to reflect that all four of us
are ordering (multi-threading).

I dunno, help!

Phil

[RG]

"Phil Powell" <so*****@erols.com> wrote in message
news:eF8eb.25672$sp2.7183@lakeread04...

You have ordered one item and placed it into your cart. Let's say you
ordered one small black t-shirt. Your cart will have the product_id,
color_id and size_id for the small black t-shirt. The quantity of this item is, let's say 30. You have one in your cart, so how many are available:

1) 29
2) 30

Now let's say that while I ordered one small black t-shirt, Sven ordered 1
small black t-shirt, Anders ordered one black t-shirt, and Olov ordered one black t-shirt. If all four of us, at one time, are all ordering the same
item and putting it into our carts, how many should there be available to
us:

1) 26
2) 25
3) 29
4) 30

This is where the contention comes in. The client wants it done "FIFO"
(First In First Out) meaning that whoever gets it first will subtract the
quantity - but I dispute that (coming from somewhat of a Java background)
that since PHP doesn't so single-threading, that means that all four of us
could order t-shirts, but the quantity has to reflect that all four of us
are ordering (multi-threading).

I dunno, help!

Phil

You gonna go round in circles here mate.
What are the chances of multiple people buying the same item in a short
period?
WHat you should do is subtract from the qty when the trtansaction is
complete.

This is why you do not want to follow your current path:
Scenario: I go to your shop and put your entire stock into my basket.
This would stop any legit shopper from being able to put anythin in there
basket.

Just reduce qty when transaction is successful
Hope this helps
RG

[Andy Jeffries]

On Tue, 30 Sep 2003 01:37:25 -0400, Phil Powell wrote:

This is where the contention comes in. The client wants it done "FIFO"
(First In First Out) meaning that whoever gets it first will subtract the
quantity - but I dispute that (coming from somewhat of a Java background)
that since PHP doesn't so single-threading, that means that all four of us
could order t-shirts, but the quantity has to reflect that all four of us
are ordering (multi-threading).

I dunno, help!

How about the quantity available is the stock quantity (in the product or
stock table) minus the "in basket" quantity (from the basket table). That
way the stock is available and allocated to people. When your baskets
expire (as per your other post) the record that allocates them will be
deleted and hence your stock will then be available for other people.

This means that RG would have to keep doing this every time his basket
expired. If you shorten your expiry time (I would say 24 hours is too
long) it makes it very unfeasible to do what RG suggests (and if someone
writes a script to hit your server every few hours you can block them).

As some advice I would set baskets to expire after 1-2 hours of inactivity
and have every page on your site update the basket time when hit. That
way if the person is still actively looking around your site the basket
expiry will be refreshed and if they leave it won't hang around for long.

You could also give people the option to "Save my basket for later" which
would then put the expiry date 10 years in the future. However, this
opens you back up to RG's attack *.

Most web customers are very quick to jump ship. If they find something
they like they'll buy it. If they actually go to the effort to put it in
their basket they will buy it there and then, unless something makes them
leave the site - when they return virtually no customer would expect their
basket to still be there (would you in a traditional shop?).

And finally, in answer to your earlier post - yes I have "some" (<g>)
experience of writing shopping basket systems.

Cheers,
Andy
* Meaning the attack that RG suggested, not that RG will actually be
attacking your server. :-)

[RG]

"Andy Jeffries" <ne**@andyjeffries.remove.co.uk> wrote in message
news:pa****************************@andyjeffries.r emove.co.uk...

On Tue, 30 Sep 2003 01:37:25 -0400, Phil Powell wrote:

This is where the contention comes in. The client wants it done "FIFO"
(First In First Out) meaning that whoever gets it first will subtract the quantity - but I dispute that (coming from somewhat of a Java background) that since PHP doesn't so single-threading, that means that all four of us could order t-shirts, but the quantity has to reflect that all four of us are ordering (multi-threading).

I dunno, help!

How about the quantity available is the stock quantity (in the product or
stock table) minus the "in basket" quantity (from the basket table). That
way the stock is available and allocated to people. When your baskets
expire (as per your other post) the record that allocates them will be
deleted and hence your stock will then be available for other people.

This means that RG would have to keep doing this every time his basket
expired. If you shorten your expiry time (I would say 24 hours is too
long) it makes it very unfeasible to do what RG suggests (and if someone
writes a script to hit your server every few hours you can block them).

As some advice I would set baskets to expire after 1-2 hours of inactivity
and have every page on your site update the basket time when hit. That
way if the person is still actively looking around your site the basket
expiry will be refreshed and if they leave it won't hang around for long.

You could also give people the option to "Save my basket for later" which
would then put the expiry date 10 years in the future. However, this
opens you back up to RG's attack *.

Most web customers are very quick to jump ship. If they find something
they like they'll buy it. If they actually go to the effort to put it in
their basket they will buy it there and then, unless something makes them
leave the site - when they return virtually no customer would expect their
basket to still be there (would you in a traditional shop?).

And finally, in answer to your earlier post - yes I have "some" (<g>)
experience of writing shopping basket systems.

Cheers,
Andy
* Meaning the attack that RG suggested, not that RG will actually be
attacking your server. :-)

You make me sound like a menace, I'm not, honestly ;P
RG

[Andy Jeffries]

On Tue, 30 Sep 2003 10:25:17 +0100, RG wrote:

* Meaning the attack that RG suggested, not that RG will actually be
attacking your server. :-)

You make me sound like a menace, I'm not, honestly ;P

That's not what I heard over on alt.l33t.haxor2! :-)

Cheers,
Andy

[Phil Powell]

I go to the shop and put the entire stock into my basket, however, I might
be doing this legitimately, meanwhile, I am going around in the shop buying
other stuff. Another legit shopper goes in and purchases just ONE item.
When I later on go to checkout with all 30 items, I of course will have a
problem; I am purchasing 30 items but 29 are only in stock because someone
else just bought one.

That CAN actually happen, so then I would have to follow my current path. :(

Phil

"RG" <[e-mail]> wrote in message
news:3f***********************@mercury.nildram.net ...

"Phil Powell" <so*****@erols.com> wrote in message
news:eF8eb.25672$sp2.7183@lakeread04...

You have ordered one item and placed it into your cart. Let's say you
ordered one small black t-shirt. Your cart will have the product_id,
color_id and size_id for the small black t-shirt. The quantity of this

item

is, let's say 30. You have one in your cart, so how many are available:

1) 29
2) 30

Now let's say that while I ordered one small black t-shirt, Sven ordered 1 small black t-shirt, Anders ordered one black t-shirt, and Olov ordered

one

black t-shirt. If all four of us, at one time, are all ordering the same item and putting it into our carts, how many should there be available to us:

1) 26
2) 25
3) 29
4) 30

This is where the contention comes in. The client wants it done "FIFO"
(First In First Out) meaning that whoever gets it first will subtract the quantity - but I dispute that (coming from somewhat of a Java background) that since PHP doesn't so single-threading, that means that all four of us could order t-shirts, but the quantity has to reflect that all four of us are ordering (multi-threading).

I dunno, help!

Phil

You gonna go round in circles here mate.
What are the chances of multiple people buying the same item in a short
period?
WHat you should do is subtract from the qty when the trtansaction is
complete.

This is why you do not want to follow your current path:
Scenario: I go to your shop and put your entire stock into my basket.
This would stop any legit shopper from being able to put anythin in there
basket.

Just reduce qty when transaction is successful
Hope this helps
RG

[RG]

"Phil Powell" <so*****@erols.com> wrote in message
news:WHdeb.27289$sp2.2015@lakeread04...

I go to the shop and put the entire stock into my basket, however, I might
be doing this legitimately, meanwhile, I am going around in the shop buying other stuff. Another legit shopper goes in and purchases just ONE item.
When I later on go to checkout with all 30 items, I of course will have a
problem; I am purchasing 30 items but 29 are only in stock because someone
else just bought one.

That CAN actually happen, so then I would have to follow my current path. :(
Phil

What you need to do then is check that the qty ordered tallies up with the
users basket at CHECKOUT.
Tell the user that they can only have 29
RG

[RG]

"RG" <[e-mail]> wrote in message
news:3f***********************@mercury.nildram.net ...

"Phil Powell" <so*****@erols.com> wrote in message
news:WHdeb.27289$sp2.2015@lakeread04...

I go to the shop and put the entire stock into my basket, however, I might be doing this legitimately, meanwhile, I am going around in the shop buying

other stuff. Another legit shopper goes in and purchases just ONE item.
When I later on go to checkout with all 30 items, I of course will have a problem; I am purchasing 30 items but 29 are only in stock because someone else just bought one.

That CAN actually happen, so then I would have to follow my current

path. :(

Phil

Ignore previous post.

At checkout, check that there is enough stock to cover the order. If there
isn't tell the user.
RG