Hi there, For those of you who have experience implementing e-commerce websites with Rails, I would like to ask for advice on whether I should persist my customers'' shopping cart in the database or just keep it in the session object? Tha pragmattic book ADWR shows an example of keeping the cart just within the session with a class that''s not based on ActiveRecord. On more robust, real-world applications, would it be best to model the cart against the database, using AR, like most of the other application models? thanks for any advice on this, Demetrius -- http://dema.ruby.com.br - Rails from a .NET perspective
You should write everything based on your requirements. If you/user/client wants the cart to persist across sessions, then use the db. If not, save it in a session. On 8/4/05, Demetrius Nunes <demetrius-fDpYTK8McCzCdMRJFJuMdgh0onu2mTI+@public.gmane.org> wrote:> Hi there, > > For those of you who have experience implementing e-commerce websites > with Rails, I would like to ask for advice on whether I should persist > my customers'' shopping cart in the database or just keep it in the > session object? > > Tha pragmattic book ADWR shows an example of keeping the cart just > within the session with a class that''s not based on ActiveRecord. > > On more robust, real-world applications, would it be best to model the > cart against the database, using AR, like most of the other application > models? > > thanks for any advice on this, > Demetrius > -- > http://dema.ruby.com.br - Rails from a .NET perspective > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Snowdevil used the db backed cart approach. I switched to a very similar model described in the book when I was starting new projects with the same codebase and i liked the results much better. It comes down to personal preference though. On 8/4/05, Demetrius Nunes <demetrius-fDpYTK8McCzCdMRJFJuMdgh0onu2mTI+@public.gmane.org> wrote:> Hi there, > > For those of you who have experience implementing e-commerce websites > with Rails, I would like to ask for advice on whether I should persist > my customers'' shopping cart in the database or just keep it in the > session object? > > Tha pragmattic book ADWR shows an example of keeping the cart just > within the session with a class that''s not based on ActiveRecord. > > On more robust, real-world applications, would it be best to model the > cart against the database, using AR, like most of the other application > models? > > thanks for any advice on this, > Demetrius > -- > http://dema.ruby.com.br - Rails from a .NET perspective > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Tobi http://www.snowdevil.ca - Snowboards that don''t suck http://typo.leetsoft.com - Open source weblog engine http://blog.leetsoft.com - Technical weblog
Tobias, What about the non-db carts did you prefer? Joshua On 8/4/05, Tobias Luetke <tobias.luetke-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Snowdevil used the db backed cart approach. I switched to a very > similar model described in the book when I was starting new projects > with the same codebase and i liked the results much better. > > It comes down to personal preference though. > > On 8/4/05, Demetrius Nunes <demetrius-fDpYTK8McCzCdMRJFJuMdgh0onu2mTI+@public.gmane.org> wrote: > > Hi there, > > > > For those of you who have experience implementing e-commerce websites > > with Rails, I would like to ask for advice on whether I should persist > > my customers'' shopping cart in the database or just keep it in the > > session object? > > > > Tha pragmattic book ADWR shows an example of keeping the cart just > > within the session with a class that''s not based on ActiveRecord. > > > > On more robust, real-world applications, would it be best to model the > > cart against the database, using AR, like most of the other application > > models? > > > > thanks for any advice on this, > > Demetrius > > -- > > http://dema.ruby.com.br - Rails from a .NET perspective > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > -- > Tobi > http://www.snowdevil.ca - Snowboards that don''t suck > http://typo.leetsoft.com - Open source weblog engine > http://blog.leetsoft.com - Technical weblog > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Mainly the fact that nothing is dumped in the DB unless a user actually creates an order as part of the checkout process. Snowdevil filled up very quickly with many abandoned carts. Granted this might be nice for statistics. On 8/4/05, Joshua Sierles <jsierles-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Tobias, > > What about the non-db carts did you prefer? > > Joshua > > > On 8/4/05, Tobias Luetke <tobias.luetke-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > wrote: > > > > Snowdevil used the db backed cart approach. I switched to a very > > similar model described in the book when I was starting new projects > > with the same codebase and i liked the results much better. > > > > It comes down to personal preference though. > > > > On 8/4/05, Demetrius Nunes <demetrius-fDpYTK8McCzCdMRJFJuMdgh0onu2mTI+@public.gmane.org > wrote: > > > Hi there, > > > > > > For those of you who have experience implementing e-commerce websites > > > with Rails, I would like to ask for advice on whether I should persist > > > my customers'' shopping cart in the database or just keep it in the > > > session object? > > > > > > Tha pragmattic book ADWR shows an example of keeping the cart just > > > within the session with a class that''s not based on ActiveRecord. > > > > > > On more robust, real-world applications, would it be best to model the > > > cart against the database, using AR, like most of the other application > > > models? > > > > > > thanks for any advice on this, > > > Demetrius > > > -- > > > http://dema.ruby.com.br - Rails from a .NET perspective > > > > > > _______________________________________________ > > > Rails mailing list > > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > > -- > > Tobi > > http://www.snowdevil.ca - Snowboards that don''t suck > > http://typo.leetsoft.com - Open source weblog engine > > http://blog.leetsoft.com - Technical weblog > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-- Tobi http://www.snowdevil.ca - Snowboards that don''t suck http://typo.leetsoft.com - Open source weblog engine http://blog.leetsoft.com - Technical weblog
Wouldn''t this be an _excellent_ application of database level logic/functions: Setup a trigger function that can delete carts after a given amount of time? If your ''shopping'' (whatever that might mean in different industries and applications) process is more than a few simple steps (click->view->pay->confirmed) I think DB carts make sense. It would be impressive to me, as an end user, if a store were able to recover the contents of my cart after... - a browser crash or accidental closing - a machine crash - a physical location change (office to home, etc) It might be an acceptable middle-ground to use optional db storage (aka adding a ''Save This Cart'' function). That would make a lot of sense to me. The argument _against_ DB carts seems to be based on technical challenges, not the user experience, and user experience should always win. -Jeff Tobias Luetke wrote:>Mainly the fact that nothing is dumped in the DB unless a user >actually creates an order as part of the checkout process. > >Snowdevil filled up very quickly with many abandoned carts. > >Granted this might be nice for statistics. > >On 8/4/05, Joshua Sierles <jsierles-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >>Tobias, >> >>What about the non-db carts did you prefer? >> >>Joshua >> >> >>On 8/4/05, Tobias Luetke <tobias.luetke-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > wrote: >> >>>Snowdevil used the db backed cart approach. I switched to a very >>>similar model described in the book when I was starting new projects >>>with the same codebase and i liked the results much better. >>> >>>It comes down to personal preference though. >>> >>>On 8/4/05, Demetrius Nunes <demetrius-fDpYTK8McCzCdMRJFJuMdgh0onu2mTI+@public.gmane.org > wrote: >>> >>>>Hi there, >>>> >>>>For those of you who have experience implementing e-commerce websites >>>>with Rails, I would like to ask for advice on whether I should persist >>>>my customers'' shopping cart in the database or just keep it in the >>>>session object? >>>> >>>>Tha pragmattic book ADWR shows an example of keeping the cart just >>>>within the session with a class that''s not based on ActiveRecord. >>>> >>>>On more robust, real-world applications, would it be best to model the >>>>cart against the database, using AR, like most of the other application >>>>models? >>>> >>>>thanks for any advice on this, >>>>Demetrius >>>>-- >>>>http://dema.ruby.com.br - Rails from a .NET perspective >>>> >>>>_______________________________________________ >>>>Rails mailing list >>>>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>>>http://lists.rubyonrails.org/mailman/listinfo/rails >>>> >>>> >>> >>>-- >>>Tobi >>>http://www.snowdevil.ca - Snowboards that don''t suck >>>http://typo.leetsoft.com - Open source weblog engine >>>http://blog.leetsoft.com - Technical weblog >>>_______________________________________________ >>>Rails mailing list >>>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>>http://lists.rubyonrails.org/mailman/listinfo/rails >>> >>> >> >>_______________________________________________ >>Rails mailing list >>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>http://lists.rubyonrails.org/mailman/listinfo/rails >> >> >> >> > >
Yes, I am more inclined to go with db cart approach because authenticated users should be able to shop, quit and return and still have their old cart filled. Although, I could just serialize the cart object to YAML and store it in the user profile for this. Jeff Casimir wrote:> Wouldn''t this be an _excellent_ application of database level > logic/functions: Setup a trigger function that can delete carts after a > given amount of time? If your ''shopping'' (whatever that might mean in > different industries and applications) process is more than a few simple > steps (click->view->pay->confirmed) I think DB carts make sense. It > would be impressive to me, as an end user, if a store were able to > recover the contents of my cart after... > - a browser crash or accidental closing > - a machine crash > - a physical location change (office to home, etc) > > It might be an acceptable middle-ground to use optional db storage (aka > adding a ''Save This Cart'' function). That would make a lot of sense to me. > > The argument _against_ DB carts seems to be based on technical > challenges, not the user experience, and user experience should always win. > > -Jeff > > Tobias Luetke wrote: > >> Mainly the fact that nothing is dumped in the DB unless a user >> actually creates an order as part of the checkout process. >> >> Snowdevil filled up very quickly with many abandoned carts. >> Granted this might be nice for statistics. >> On 8/4/05, Joshua Sierles >> <jsierles-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> >>> Tobias, >>> >>> What about the non-db carts did you prefer? >>> >>> Joshua >>> >>> >>> On 8/4/05, Tobias Luetke >>> <tobias.luetke-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > wrote: >>> >>>> Snowdevil used the db backed cart approach. I switched to a very >>>> similar model described in the book when I was starting new projects >>>> with the same codebase and i liked the results much better. >>>> >>>> It comes down to personal preference though. >>>> >>>> On 8/4/05, Demetrius Nunes >>>> <demetrius-fDpYTK8McCzCdMRJFJuMdgh0onu2mTI+@public.gmane.org > wrote: >>>> >>>>> Hi there, >>>>> >>>>> For those of you who have experience implementing e-commerce websites >>>>> with Rails, I would like to ask for advice on whether I should persist >>>>> my customers'' shopping cart in the database or just keep it in the >>>>> session object? >>>>> >>>>> Tha pragmattic book ADWR shows an example of keeping the cart just >>>>> within the session with a class that''s not based on ActiveRecord. >>>>> >>>>> On more robust, real-world applications, would it be best to model >>>>> the cart against the database, using AR, like most of the other >>>>> application >>>>> models? >>>>> >>>>> thanks for any advice on this, >>>>> Demetrius >>>>> -- >>>>> http://dema.ruby.com.br - Rails from a .NET perspective >>>>> >>>>> _______________________________________________ >>>>> Rails mailing list >>>>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>>>> http://lists.rubyonrails.org/mailman/listinfo/rails >>>>> >>>>> >>>> >>>> -- >>>> Tobi >>>> http://www.snowdevil.ca - Snowboards that don''t suck >>>> http://typo.leetsoft.com - Open source weblog engine >>>> http://blog.leetsoft.com - Technical weblog >>>> _______________________________________________ Rails mailing list >>>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>>> http://lists.rubyonrails.org/mailman/listinfo/rails >>>> >>> >>> _______________________________________________ >>> Rails mailing list >>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>> http://lists.rubyonrails.org/mailman/listinfo/rails >>> >>> >>> >>> >> >>-- http://dema.ruby.com.br - Rails from a .NET perspective
Demetrius, While it would be easy to serialize & store, keep in mind that you are breaking database commandments. Anytime you store data in a "composite" field you are making that data less accessible. For instance, I could imagine a situation where you want to discount a product. You need to make sure that anyone with the item already in a saved cart gets the discount. Or, maybe you want to alert all users with the item in a saved cart that the item is on sale. In either case, having a serialized pile of YAML takes the job of finding those users away from the highly-specialized data finding tool (the database) and puts the responsibility on the more error-prone, generally slower application (rails et al). Know what I''m saying? -Jeff Demetrius Nunes wrote:> Yes, I am more inclined to go with db cart approach because > authenticated users should be able to shop, quit and return and still > have their old cart filled. > > Although, I could just serialize the cart object to YAML and store it > in the user profile for this. >
Jeff Casimir wrote:> While it would be easy to serialize & store, keep in mind that you are > breaking database commandments. Anytime you store data in a "composite" > field you are making that data less accessible.Yes, but a good programmer knows when to break the rules right? ;-)> For instance, I could imagine a situation where you want to discount a > product. You need to make sure that anyone with the item already in a > saved cart gets the discount. Or, maybe you want to alert all users > with the item in a saved cart that the item is on sale. In either case, > having a serialized pile of YAML takes the job of finding those users > away from the highly-specialized data finding tool (the database) and > puts the responsibility on the more error-prone, generally slower > application (rails et al). > Know what I''m saying?Yes, I know what you''re saying and in this case, you''re absolutely right. Thanks! rgds Demetrius> Demetrius Nunes wrote: > >> Yes, I am more inclined to go with db cart approach because >> authenticated users should be able to shop, quit and return and still >> have their old cart filled. >> >> Although, I could just serialize the cart object to YAML and store it >> in the user profile for this. >>-- http://dema.ruby.com.br - Rails from a .NET perspective
Jeff Casimir <jeff-+RlNNtFrnNmT15sufhRIGw@public.gmane.org> writes:> Wouldn''t this be an _excellent_ application of database level > logic/functions: Setup a trigger function that can delete carts after > a given amount of time?Generally triggers operate on a row after /that row/ has been "touched" in some way, no? If a row is "stale", it''s never touched again. This seems to me a better application of a cron job type thing (or do such cron style triggers exist in the db you''re using? That''d be cool if they did.) -- I tend to view "truly flexible" by another term: "Make everything equally hard". -- DHH
Michael,
I might be using the wrong word ("trigger") as I agree that they are
usually reactionary. I swear I read about creating data expiration
functions in my PostgreSQL book, but I don''t have it with me to lookup.
A quick (though not exhaustive) google check didn''t dig up the
solution. Any with experience in the area?
-Jeff
Michael Campbell wrote:
>Generally triggers operate on a row after /that row/ has been
>"touched" in some way, no? If a row is "stale",
it''s never touched
>again. This seems to me a better application of a cron job type thing
>(or do such cron style triggers exist in the db you''re using?
That''d
>be cool if they did.)
>
>
>
Jeff Casimir <jeff-+RlNNtFrnNmT15sufhRIGw@public.gmane.org> writes:> Michael, > > I might be using the wrong word ("trigger") as I agree that they are > usually reactionary. I swear I read about creating data expiration > functions in my PostgreSQL book, but I don''t have it with me to > lookup. A quick (though not exhaustive) google check didn''t dig up > the solution. Any with experience in the area?Just in the "cron" style. In various positions I''ve been in we have had batch jobs that run periodically that do reporting, creating summary tables for later use, database cleanup of expired data, and the like. Usually fired off by cron (or occasionally by whatever job scheduler is built into the db, if one exists). I''ve usually called these particular types "purge jobs". -- I tend to view "truly flexible" by another term: "Make everything equally hard". -- DHH