-
Notifications
You must be signed in to change notification settings - Fork 899
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Removes item_subtype requirement for model-specific limits. #1309
Removes item_subtype requirement for model-specific limits. #1309
Conversation
ab83036
to
d79d6d6
Compare
@jaredbeck Any thoughts on this approach? |
This PR has been automatically marked as stale due to inactivity. |
@aried3r Do you have time to look at this? I've been busy with some other stuff lately. |
I had a quick look. It seems reasonable and all specs pass. Are we perhaps lacking a spec that proves that it works without the |
@PhilCoggins sorry for the delayed review. Please let us know if you have trouble making the requested changes. |
d79d6d6
to
bca9aa5
Compare
@jaredbeck I'll get this updated early this week, today or tomorrow evening. |
* When enforcing limits for a model, it was previously required to have the item_subtype column on the versions table to obtain the configured limit for a given model type, especially for models subclassed via STI. * This change instead references the item on the version record, which is already available via the association cache, to determine the properly configured limit. This change drops the requirement of having item_subtype to configure model-specific limits.
bca9aa5
to
12c0525
Compare
@jaredbeck Updated |
Thanks Phil, nice work |
Released in 12.1.0 |
When enforcing limits for a model, it was previously required to
have the item_subtype column on the versions table to obtain the
configured limit for a given model type, especially for models
subclassed via STI.
This change instead references the item on the version record,
which is already available via the association cache, to determine
the properly configured limit. This change drops the requirement of
having item_subtype to configure model-specific limits.
Assuming there are no issues with simply referencing
item.class
to determine the configured limit, this should be a better setup, as it doesn't requireitem_subtype
.Note: The example that I removed assumes that in the absence of
item_subtype
, the global limit would be used - even if a model had its own configured limit. This spec was irrelevant because it was not possible to have simultaneously definedlimit
withhas_paper_trail
and not haveitem_subtype
in yourversions
schema, because an exception would be thrown.Fixes #1307