Got a strange question - how can I instantiate an object, technically an AR-backed model, from a hash; however, I do not want any DB call being made? So far I've bee doing `User.new(hsh)` as a quick example, but that is essentially a `new_record`.
how can I instantiate an object, technically an AR-backed model, from a hash; however, I do not want any DB call being made? So far I've bee doing `User.new(hsh)` as a quick example, but that is essentially a `new_record`.
matthewd: well, it has already shown huge improvements. The way I've set it up is that logic is stuffed into procs; if a matching cache key doesn't exist in the configured Redis DB, the proc is evaluated and the result is persisted at the respective key. There are jobs also that run to 'prime' the cache etc. As for model syncing, yes, there are AR hooks to call various cache busting strategies
matthewd: agreed, there are other dangers due to the lack of mutexes on the Redis keys; i.e. a job could potentially wipe/mutate contents of a key, but I've thrown safeguards in.
Radar: project I'm on uses https://github.com/rails-api/active_model_serializers heavily, and that's a pretty horrid gem. In a mature app, when lots of models are serialised (and relations are serialised) you find a terrible cascading effect, and repeated DB calls for essentially the same data. Admittedly, the caching approach is a bandage on top of this.
matthewd: before the caching approach, loading a very dynamic landing page would take 2-3 minutes on a m4.xlarge EC2 isntance. with the caching, it's down to 14-15secs.
I've cached a record in redis (by hand) and am performing a deserialisation, also by hand. Right now, I'm returning the model by doing Model.new(hash); where the hash is the deserialised info.
How can I make that PORO (Model) be the same as the model that one would fetch by doing Model.find() ?
That's a good point Pro777. That 'organisation' (or convention over configuration nature) of Rails also _generally_ makes it easier for new comers to a project to easily re-familiarise themselves with a code-base they've never seen before, well usually.
^^ only depends on how far a team sticks to the 'usual Rails' way, and there's a lot of reasons not to as well.
hey all - I'm trying to trace AR (DB) calls in a controller action and correlate those calls to actual code. I've basically killed all before filters except 1, and am still seeing loads of DB calls.
I'm looking at planning to handle concurrency at the stack level, are there any ball-park metrics one should aim for in general? I.e. should a stack _generally_ be capable of say 100 concurrent requests?