Fixes a problem where after dup the dup'd model and the original model share a translation instance, which means that if you mutate a translated field on the dup and save it, the original becomes a clone of the dup.
We were running in to this in our efforts to use spree, so there's at least one major implementation that is effected.
Thanks in advance!
Fixes a problem where after dup the dup'd model and the original mode…
…l share a translation instance, which means that if you mutate a translated field on the dup and save it, the original becomes a clone of the dup.
I'm not sure why the travis build failed :(. I don't have all of those platforms available, but the test suite passes locally for me in a variety of rubies.
Yeah something strange is going on, locally the tests pass sometimes and fail other times for me. The failures on Rails 4.1 may be fixed in #353 if we can make the fix backwards compatible.
After a lot of debugging I realized I came across with the same issue as @hypomodern. This issue makes the gem mess with a LOC in friendly_id gem and I'm having problems using them together, @shioyama can I help on anything to make some progress on this matter?
Thanks a lot in advance!
@brauliomartinezlm thanks for confirming, that bumps the priority of this. I'll look into it on the weekend and merge if there are no issues.
Thanks a lot!
Just to give further feedback about this, I bumped to this PR in the app I'm working with (which makes an extensive use of globalize and friendly_id) and everything worked out correctly. Didn't see any colateral issues by applying it. I'll try to think about this issue on myself during the weekend to see if I can come up with something, because although it fixes the issue I'm not sure if it's the right thing to clear the memoized value here or a refactor is needed not to share the adapter (I'm a newbie with globalize so maybe this PR is actually the way to go, just not sure).
Let me know if I can help with something, thanks again!
@brauliomartinezlm ah, sorry didn't have time to look into this over the weekend. @parndt any thoughts on this?
I'd be thrilled for @brauliomartinezlm to come up with a refactored solution rather than clearing values. However, if that doesn't work then I guess we'll just merge this PR.
Any progress on finding another solution to this?
@JDutil @hypomodern merged it
@parndt could we get a new gem release including this please?
@JDutil seems reasonable; can you see anything else in the change history that would cause any problems for 4.0.x?
@parndt I don't think so, but to be honest I'm not very familiar with this libraries codebase. Only changes that look potentially bad are these Thread changes v4.0.2...master#diff-0df2502195bd5448967f47dc781b4b96L55 but I'm not really clear on the context of it.
@JDutil @hypomodern version 4.0.3 is released with this code, thanks!
I hope Spree are able to contribute other useful changes and improvements in future! ❤️
Thank you @parndt
@hypomodern after updating spree_i18n to globalize 4.0.3 I'm still receiving validation error for spree-contrib/spree_i18n#386 did you make changes there as well to fix the problem?
@hypomodern Thank you very much!