Product Entity Attribute

[Alex]

Hey all,

I'm about 1.5 years into learning django-oscar and want to extend my thanks to the Oscar contributors/community for providing this amazing e-commerce framework.

I have my first questions that are somewhat architectural/best-practices in nature.

For context, my application is a service for auto-quoting 3D prints -

1) The design pattern I'm currently going with is for service-related information to be related to a newly created Product() through a service_ticket ProductAttribute() of type=entity. Is this the preferred way - over storing my service_ticket information (filament_type, filament_color) into individually specified ProductAttribute()s. Both seem to be non-problematic. Does anyone out there have extensive use of type=entity in there stores? Have you run into any unexpected limitations with it?

2) I notice that AbstractOption's tuple of TYPE_CHOICES does not include a so-called 'OPTION' - they are currently: (TEXT, INTEGER, BOOLEAN, FLOAT, DATE); I'm suspecting this was due to  the fact that generally a StockRecord needs to be 'related' to each Product() at the end of the day and if an AbstractOption were to include an 'option' required to be selected by the user than it could be at odds with the StockRecord paradigm which defines - a priori - the quantity of a stock by all the various partners and to do so this needs to be tied to an explicit product. However I can think of a counter-point where you want the user to interface with an option group such as select the color of a macbook-pro (silver, space-gray, rainbow) and select how much ram you want (256, 512, 200TB)

(see here: https://www.amazon.com/Apple-MacBook-13-inch-256GB-Storage/dp/B08N5N6RSS/ref=sr_1_3?dchild=1&keywords=macbook+pro&qid=1633904184&sr=8-3) -

I suppose this could be done with ProductVariants() but the number of said variants you would have to stand up would go up exponentially if I'm not mistaken and becomes unwieldy after encompassing the equivalent of say 3 option groups at 3 selections each - 3^3 = 9 ProductVariants(). The other possibilities for why I think this wasn't implemented is

   a) complexity - there are some hidden difficulties maybe with lazy() or through that I'm not experianced enough to recognize

   b) simply outside the the scope of Oscar - which wasn't intended to cover so called ConfigurableProducts() right out of the box but definitely supports this possibility just by extending or overriding the necessary class - in this case ProductOption()

Thoughts?

Sincerely,

Alex

[solari...@gmail.com]

I think the `Option` model is what you need here - it can be extended without too much difficulty to handle the use case you have.

I don't quite understand the question in point 2 in your post - but broadly speaking there are two approaches. If you hold separate stock for different variations of a product, then these should be given separate stock records with a variant for each. If the stock is the same and the product just gets customised based on what the customer chooses, then use options. If options vary with price, then there is some guidance here on how to handle that: https://github.com/django-oscar/django-oscar/issues/1515#issuecomment-77702476 .

Hope this helps,

Samir

[Alex]

Thanks Samir -

I'll take a look at option again as well as dig into the thread you linked - Sorry for the delayed response -

Sincerely,

Alex