I was wondering if it was possible to automatically update a wishlist when someone purchases something off of it. I think the answer is no since there is no way to identify that specific user's item(s) but thought I'd throw it out there just to see before I start creating a way. Thanks.
2.) You do realize that matching by ProductVariantId isn't going to quite work? You need to match by CustomerId somehow, not by ProductVariantId. Anyone could order the same ProductVariant and you would mistake it as someone ordering it off of that person's list. At the moment, I've added a column to the row to identify the original Wishlist's CustomerId so I can properly identify whose list the item came from.
Sorry if that seemed harsh but it seemed kind of crazy to try and match on something that could return multiple wishlists. I just wanted to test the waters out and see if someone had already done such a thing.
(yes, it does seem a bit odd: the customer's cart has both ShoppingCart type items and Wishlist type items)
... Linq/EF does the same joins your saying SQL would do. Run SQL Profiler and you'll see exactly what I mean (you'd be surprised at the SQL statements EF creates). Either way, it is a headache performance wise to search in that manner, hence why I worked out a way around it by just tying in an extra field to maintain where the item in the user's cart came from (0 if just adding directly to cart, CustomerId of person's wishlist otherwise). EF is great to a certain degree but sometimes it creates more headaches than necessary.
Btw, what makes you think I don't understand Linq/EF? That's kind of a presumptious opinion that slightly irks me for some reason. I've used Linq and EF for quite a while and am aware of how useful it is, as well as what EF's limitations are.
No reason to be irked. I was just pointing out a way that works. Yes, I'm aware of EF to SQL underneath, and yes, it's not always pretty and does not perform optimally; in the above case, though, the cart data is probably cached. Personally, I think you get a bigger headache trying to work around it - figuring out how, adding new fields, etc. And, when it comes time to upgrade to new nopC, you'll have to diff/merge code.
How do you figure it is a bigger headache with my workaround? You're searching through 3 tables to match data whereas my workaround uses one. Yes, there are issues when upgrading, but that same issue is present should I follow your example as well. The merge wouldn't be that horrible since I added only one field that can be left blank, so only the Core, Services, and Web need dealt with. The Web would need dealt with in your case.
Aside from that, this functionality would be the furthest thing from my concerns should I upgrade due that I've heavily modified several pieces of Nop to work with the project I'm currently on. This isn't even the tip of the iceberg, lol.
Anyways, I do have a working piece currently with my solution. I may go back and create a Plugin though since that does seperate things out a bit more.
It just dawned on me, I may have forgot one piece of information. I'm not so concerned when a user is updating their own wishlist, it's more of a user ordering stuff out of other people's wishlist. That is the case I'm trying to catch. My apologies for not explaining that better earlier.
Many thanks to mb for your suggestion. I went back and changed my implementation into a plugin. I'm pretty happy with it thus far and it functions perfectly. Thanks for that suggestion.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.