Any ideas appreciated. - thanks.
Matthew
I'm looking to store info thats a bit more complex than just a item
number, so I'm considering storing temporary items created in guest
sessions in a table along with items saved in users sessions.
The temporary items would need to be flagged in someway in the DB &
cleaned out somehow....
Any thoughts?
Matthew
Beaker sessions.
Wichert.
either beaker sessions, or just use a beaker session id as the
shopping cart / user id
you could do a dbtable that has this:
table: cart
id bigserial primary key not null,
session_id char(32) unique ,
useraccount_id bigint references useraccount(id),
allow null in session_id and useraccount_id , so that session carts
can be merged into useraccount carts after registration, and vice-
versa.
Once a user logs in, the session object is converted to a 'real'
shopping cart which, in my case, is bound to the user_id.
Of course, the annoying part of this is that this session -> cart
conversion has to happen, but its not really that bad (i have a pretty
simple use case).
DD.
I found a couple of threads on stackoverflow on similar questions:
http://stackoverflow.com/questions/1969711/best-way-to-place-temporary-data-for-an-webapp
http://stackoverflow.com/questions/964476/store-in-session-data-vs-store-in-sql-database-for-temporary-data
Although it seems there will be a performance penalty for this type of
arrangement, I think I'll attempt to implement something like what
Jonathan suggests. Hopefully the decision doesn't turn out to be a
bad one... Oh well it's all just a learning experience eh?
cheers again
Each session has a cart. Each cart may belong to more than one
session.
A customer can identify with more than one session, although each
session can only identify with up to one customer.
This way, the customer can put stuff in their cart at home, go to
work, add some more stuff, and then come home, and have everything in
their cart. The customer has two active sessions because the browser
at work and the browser at home don't share cookies. Plus, your logs
will have a more realistic picture of what's really going on, since
each session maps to exactly one browser.
On Jan 25, 9:54 pm, Matt Woolnough <m...@woolnough.com.au> wrote:
> Thanks guys for your input.
>
> I found a couple of threads on stackoverflow on similar questions:
>
Thanks for the suggestion, I just can't work out how I'd match up the
individual sessions to the same cart if the user is not signed in.
Am I missing something here?
Matthew
On Jan 26, 6:35 pm, "jgard...@jonathangardner.net"
<jgard...@jonathangardner.net> wrote:
> A better idea might be to map carts to sessions, and then sessions to
> customers.
>
> Each session has a cart. Each cart may belong to more than one
> session.
>
> A customer can identify with more than one session, although each
> session can only identify with up to one customer.
>
> This way, the customer can put stuff in their cart at home, go to
> work, add some more stuff, and then come home, and have everything in
> their cart. The customer has two active sessions because the browser
> at work and the browser at home don't share cookies. Plus, your logs
> will have a more realistic picture of what's really going on, since
> each session maps to exactly one browser.
>
> On Jan 25, 9:54 pm, Matt Woolnough <m...@woolnough.com.au> wrote:
>
>
>
> > Thanks guys for your input.
>
> > I found a couple of threads on stackoverflow on similar questions:
>
> >http://stackoverflow.com/questions/1969711/best-way-to-place-temporar......
>
> > Although it seems there will be a performance penalty for this type of
> > arrangement, I think I'll attempt to implement something like what
> > Jonathan suggests. Hopefully the decision doesn't turn out to be a
> > bad one... Oh well it's all just a learning experience eh?
>
> > cheers again- Hide quoted text -
>
> - Show quoted text -