如何实现基于会话的“添加到购物车” Rails 中的函数
您好，我在 Rails 电子商务应用程序中实现“添加到购物车”功能时遇到问题。这里我不讨论check out功能。只需“添加到购物车”即可。无需用户登录其帐户即可将商品添加到购物车。用户完成添加到购物车后，在结帐之前用户将登录。我的问题是存储添加到购物车的这些商品的最佳方式是什么。我正在尝试使用会话。如果用户仅向购物车添加任意数量的一种产品，我可以轻松实现此目的。但是，如果用户检查了多个不同数量的商品，如何临时存储信息。我需要一个数据结构来存储这些信息，但不知道使用哪个数据结构。 我的意思是这样的：
Session_id | product_id | quantity
wisidiri4i | 1234 | 3
349sksksks | 3452 | 6
等等......
使用哈希我可以存储一个项目，但如何存储多个项目？ 使用数据库表，我可以做到这一点，但是如果用户离开时将添加到购物车的商品但没有结帐，如何从表中删除这些记录？
我被困在这里了。 任何帮助将不胜感激。 谢谢
Hi I have a problem implementing add to cart functionality in my rails e-commerce app. Here I am not talking about check out function. Just "add to cart". Items can be added to cart without requiring users to log in to their accounts. Once the user finishes adding to cart, then before check out user will log in. My problem here is what is the best way to store those items added to the cart. I am trying to use session. I can easily implement this if the user adds to cart JUST one product with any quantity. But how to store the information temporarily if user checks out multiple items with different quantities. I need a data structure to store this information but don't know which data structure to use.
I mean something like this:
Session_id | product_id | quantity
wisidiri4i | 1234 | 3
349sksksks | 3452 | 6
And so on.....
Using hash I can store one item, but how to store multiple items??
Using DB table, I can do this but how to delete those records from the table if user leaves with items added to cart but without check out?
I am stuck here.
Any help would be appreciated.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一般来说，您应该使用会话 ID 和数据库来存储产品。这使会话信息保持最少（仅 ID）并为您提供最大的灵活性。在我看来，将这样的数据结构放入会话存储中是一个坏主意：如果您决定稍后更改数据结构怎么办？您必须同时支持旧版本和新版本的数据结构。
正如您所指出的，基于数据库的解决方案的问题是，在某些时候您需要从数据库中清除未购买的商品。这通常是定期完成的（例如，清除超过 X 天的购物车），其中时间范围可以基于数据库的大小（如果在 3 个月后清除购物车，数据库会增长多大？6 个月）以及人们是否可能会在未来某个时候返回（他们会在 3 个月后返回吗？6 个月后返回吗？）。
如果您决定将信息存储在会话中，那么您可能想要进行某种类型的简单序列化，例如：
这里唯一的限制是会话数据可以有多长（肯定要添加长度检查）。
In general, you should use the session ID along with a database to store the product(s). This keeps the session information minimal (just the ID) and provides you with the most flexibility. IMO its a bad idea to put a data structure like this into the session store: what if you decide to change the data structure later? You'd have to support both the old and new versions of the data structure.
As you noted, the problem with a db-based solution is that at some point you need to clear out the unpurchased items from the database. This is typically done periodically (eg. carts over X days old are purged), where the timeframe can be based on the size of the database (how big does it grow if carts are purged after 3 months? 6 months) and whether people are likely to return at some point in the future (will they return 3 months later? 6 months?).
If you decide to store the info in the session, then you'd probably want to do some type of simple serialization, eg:
The only limitation here is how long the session data can be (definitely add a length check).