I noticed that the maximum number of times a coupon can be used is implemented as a field. I wonder why this is the case. I would think that it makes much more sense to store this data in the commerce_coupon table. I know some coupons might have infinite uses. Infinite uses is IMO a selection of used like 1, 10, 33 ect. Since this is something we would want on all coupons, we should implement it as core data, instead of using a field.

Comments

pcambra’s picture

pcambra
he/him
Primary language Spanish
Location Asturies
CreditAttribution: pcambra commented
Status: Active » Closed (won't fix)

I don't think we care if it's a field or a property, specially when in D8 everything is going to be a field... the number of uses gets created with the entity and attached to it, I don't see any reason not to have it as a field as it is locked and so on (similar to price field)

googletorp’s picture

googletorp CreditAttribution: googletorp commented
Status: Closed (won't fix) » Active

The reason to do it is performance.

Queries will be faster since 1 less join is needed.

The amount of space needed to store the number is about 10 - 20 timer greater when using a field, since you have to store

Entity type
Bundle
deleted
entity id
revision id
language
delta
the actual value

And you need to store it twice.

It also brings the extra overhead complexity of having 2 more tables created in the database.

You might think - oh - what's two more tables? I have had clients who had thought the same and ended up with a Drupal database with more than 700 tables.

Unless there is actually a good reason is use a field like the case with price fields, that

• requires a special data structure
• Required a specific rendering
• etc

which is made reusable with fields, I don't see what we gain by using a field.

Have you given this some thought as to why this should be a field? The same could be said about the actual code. It's fine if you don't want this, but would like to know the reason behind this design decision.

pcambra’s picture

pcambra
he/him
Primary language Spanish
Location Asturies
CreditAttribution: pcambra commented

Have you given this some thought as to why this should be a field? The same could be said about the actual code. It's fine if you don't want this, but would like to know the reason behind this design decision.

Basically the "historic" reason it's a field is because it was a field when I started maintaining this and I never consider it as a priority or something we should change.

Thought I had mentioned it in the issue but it seems not, I want to find time to roll a 2.x based in commerce discount and there "times used" is a field (both uses and max uses) too for doing calculations and displays so I'm reluctant to change the 1.x as it will be obsolete sooner than later (I hope) and migration will be easier as a field. However, feel free to open an issue there, as it would probably need a big rewrite.

Also, I understand the performance reasons but I tend to think it's a big deal at this point as we have bigger concerns on that area by design such as #1797184: Every single coupon loads in checkout