For anyone waiting on the dirty tracking fix, it was done, but some issues were pointed out, and I've figured out how to handle them, see: https://github.com/shioyama/mobility/pull/347#issuecomment-544742401
I'll try to get to this on Wednesday. There's an issue that master and the 0-8-stable branch have diverged quite a lot (my fault...), so I need to change them more-or-less separately. But once master is done and passing, I'll make the changes to 0-8 and release 0.8.9.
- We have multi-tenancy thus potentially different fallbacks per tenant, so a global static hash won't do, it will need to be a proc
- Adding mobility and setting translates: :name in our Product model, we get empty product names everywhere because there is no data migration for records (readme appears to be tailored to new projects or migrating from globalize, but not on how to add to an existing project)
- As an alternative to fallbacks we are considering overriding the getter / setter (as in shioyama/mobility#335) to default to the native db column and potentially avoid unnecessary JOINs when the visitor locale is the same as the default tenant locale
- We are using MySQL which has json support in the later versions in case we want to use the serialized / container approach, but it appears it has not been as thoroughly tested as the PG jsonb equivalent
- Finally, we are currently stuck on rails 4.2, with all that may entail :-(
Any thoughts would be appreciated, TIA
Hey, sounds like a bit of a challenge you've got there. Let me respond point by point.
- Fallbacks as a proc is something I'd like to do and there's a PR for it, but the implementation needs some work: shioyama/mobility#328
- About the empty product names thing, this is a common pain point and something I'd like to eventually provide support for (i.e. migrating from a "normal" column attribute to a translated one). I don't have a solution for it but I consider it a problem that Mobility should solve or at least support.
- Json with MySQL is not supported currently. There was a PR for it but it never really got anywhere: shioyama/mobility#271 This is not a priority for me, if you want it I'd ask you to make a PR which I can help with.
- Rails 4.2 support is and will continue to be incomplete, and at some point I will start dropping the conditionals and remove tests for it, so don't really count on it. Sorry!
Those are my quick thoughts. I won't be doing anything Mobility-related for a while probably, and first priority is cleaning up the code to release v1.0, so the first and second points above would come after that (or possibly as a part of that).
- Is the PR for fallbacks per-attribute or will we also be able to set a proc on a global level?
- I suppose the native column is not even required to be present with globalize or mobility, right? It is in essence a virtual attribute
- I read in the readme that a proc can be provided as a fallback generator, but don't quite understand how it's supposed to work
Sorry for the barrage of questions!
Seems we may need to roll our own solution with MySQL json using the native column primarily and getting / setting the translations as needed
- the fallbacks proc thing works exactly like other fallbacks, per attribute, can be set globally as well
- native column is not required at all, and not assumed to be present (for Mobility). I'm not following Globalize anymore so can't say for that gem.
- the proc as fallbacks generator was a bad design decision, and it's not what you're looking for. It's something else and mostly just confusing so probably will be removed.
Mobility::Plugins::Fallbacks.with_fallbacks(:en) { # fallbacks are overridden }
master uses a different plugin config (no longer an assignment, but is a function) but this is not referred to in docs (the docs seem to lag master which makes sense for rubygems users)
To answer your second question (quickly): master is a WIP toward a 1.0 release, so there are some fundamental things that have changed there. They are not yet documented. All released versions are on the 0.8 branch, and I'm keeping 0-8-stable up to date with any new changes I merge in.
It's complicated and wish I could get out the 1.0 release, but just no time right now so for now 0.8 is stable and the one you should use. Make PRs to master and I'll port back to 0.8 and release there for now.
options in the fallthrough accessor actually has some value (otherwise it would be empty and effectively would not be passed to the super)
select
Ok, so I have some insight into this problem actually. I noticed you're aliasing query results in that SQL (as coming_30_days etc). That means those attributes will be actually fetched using method_missing rather than defined methods, which explains the relation to the change in 0.8.12.
For background on that (purely discussion of ActiveRecord), watch my RailsConf talk on the topic: https://www.youtube.com/watch?v=PNNrmNTQx2s&feature=emb_logo
coming_30_days on your model will end up hitting method_missing. For a model with Mobility enabled, and using fallthrough accessors (which are there if you're using dirty tracking), you will pass through that code that was changes. So that's the connection.
method_missing is not supposed to actually include keyword arguments:method_missing(m, *a, &b)method_missing, is actually breaking the API. Previously it was hiding that by not passing the keyword arguments to super, but now since it is it can break other stuff. Ironically that was what the original PR was trying to fix.
method_missing without any **options, the options are being converted to a hash, which does not match the signature that ActiveRecord expects.