-
Notifications
You must be signed in to change notification settings - Fork 82
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
Fix reader creation #572
base: master
Are you sure you want to change the base?
Fix reader creation #572
Conversation
…s saving parent when translations have validations
… prevent valid? on parent model (issue shioyama#569)
@shioyama could you take a look? You can update the failing few specs since they seem to be testing internal logic (which I think should not be tested, or said another way, the test should not depend on internal implementation, such as that reading an attr creates a translation in the db). |
Thanks @mrbrdo , really appreciate it. I'll have a look this weekend. |
@shioyama did you manage to take a look? |
@shioyama managed to check this yet? |
@@ -85,7 +85,8 @@ module Table | |||
# @!group Backend Accessors | |||
# @!macro backend_reader | |||
def read(locale, **options) | |||
translation_for(locale, **options).send(attribute) | |||
translation = translations.in_locale(locale) | |||
translation.send(attribute) if translation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm I think this is what the presence
plugin is for. Also you have thrown away the **options
here which will be a problem.
It seems like github actions didn't run on this PR... not sure why 🤔 |
Sorry @mrbrdo I can't seem to approve github actions on this, but I tried changing some repo settings. Can you push a new commit? I'll try to kick CI so it runs. You're not actually getting test results, I'm pretty sure tests will fail on this change. |
Ok I don't know what's going on with actions but when I run this locally 4 tests fail:
|
Those specs are not that important, they're basically testing implementation details. The bigger problem is that this change kills the cache: mobility/lib/mobility/backends/table.rb Lines 134 to 141 in 7683433
The cache patches There should be a way to improve that, but it would require a bit more work & thought. |
The problem is the way caching is done, which depends on building translations and then caching those built translations. And actually, the tests are mostly testing implementation details but not entirely.
This is a real issue, because the cache is basically not working. In this PR I don't have a good solution unfortunately. The problem is that "caching" as a concept is tricky across backends. I've never really been completely happy with the current implementation but it's definitely not as simple as just swapping out a couple lines. Probably a complete rethink would be necessary to really fix this issue. |
I agree. But there is a case to be made that correct functioning is more important than caching. I think this issue is specific to table-based backends and pretty sure it could be solved in that context only while keeping caching working. Crucially the built empty translations should not be saved upon saving the parent, in some implementational way or another. This could even be an ActiveRecord-specific issue, as I don't remember if Sequel automatically saves associated records like that. I think you will agree that even on a conceptual level, reading an attribute should never really append records to the DB (even though if this is done as a hook after the fact). In that way the AR table implementation is faulty. Potentially even race conditions exist where this would create several Translation records in the DB for the same model, and that would really be hell. |
I agree that it can, but I don't believe it's trivial to do within the confines of what is currently expected of the cache, if we want to keep the code relativley simple. A solution would be to have some wrapper for the built translations which can handle the
I agree. I would only note that nobody has raised this as an issue so far in the 5 years since Mobility has been released. Which, honestly, is a bit surprising 🤔 but that's the reason this hasn't been looked into further. Anyway Globalize might be a reference point: And Again though Globalize is not build the same way as Mobility. |
To me this seems not to break anything and fixes #569
Please note I did not update existing specs that explicitly test that translations have been created on read, which is now not the case so they are failing. However I do not see any reason for attr reader to build translations on parent.