I am assuming this an appropriate place to discuss this, but if it isn’t my apologies- just let me know. Just a Rails 4-ish thing.
Am attempting to pull AMS (active_model_serializers), strong_parameters, and the “permitter” strategy that Adam Hawkins is using: http://broadcastingadam.com/2012/07/parameter_authorization_in_rails_apis/
Code so far is here (in the integrate-twinturbo_strategy_for_param_authr branch if you clone): https://github.com/garysweaver/restful_json/tree/integrate-twinturbo_strategy_for_param_authr
Autogenerated serializer and permitter classes for each model that has a table (~270 permitters, ~270 serializers), which means a lot of attribute and association name duplication, but it’s what I’ve got for now.
Running into some circular reference issues:
Started GET “/service/my_models” for 127.0.0.1 at 2012-10-01 16:56:29 -0400 Processing by MyModule::MyModelsController#index as JSON MyModel Load (3.5ms) SELECT “my_models”.* FROM “my_models” MyModel2 Load (2.0ms) … MyModel3 Load (0.9ms) … MyModel4 Load (0.7ms) … MyModel5 Load (7.0ms) … MyModel6 Load (0.5ms) … MyModel7 Load (2.9ms) … MyModel8 Load (0.7ms) … MyModel9 Load (0.7ms) … MyModel10 Load (0.7ms) … MyModel11 Load (10.3ms) SELECT “my_model_11s”.* FROM “my_model_11s” WHERE “my_model_11s”.“my_model_10_id” = 123 MyModel12 Load (0.9ms) SELECT “my_model_12s”.* FROM “my_model_12s” WHERE “my_model_12s”.“my_model_10_id” = 123 MyModel10 Load (0.7ms) SELECT “my_model_10s”.* FROM “my_model_10s” WHERE “my_model_10s”.“id” = 123 LIMIT 1 CACHE (0.0ms) SELECT “my_model_11s”.* FROM “my_model_11s” WHERE “my_model_11s”.“my_model_10_id” = 123 CACHE (0.0ms) SELECT “my_model_12s”.* FROM “my_model_12s” WHERE “my_model_12s”.“my_model_10_id” = 123 CACHE (0.0ms) SELECT “my_model_10s”.* FROM “my_model_10s” WHERE “my_model_10s”.“id” = 123 LIMIT 1 CACHE (0.0ms) SELECT “my_model_11s”.* FROM “my_model_11s” WHERE “my_model_11s”.“my_model_10_id” = 123 CACHE (0.0ms) SELECT “my_model_12s”.* FROM “my_model_12s” WHERE “my_model_12s”.“my_model_10_id” = 123 CACHE (0.0ms) SELECT “my_model_10s”.* FROM “my_model_10s” WHERE “my_model_10s”.“id” = 123 LIMIT 1 … CACHE (0.0ms) SELECT “my_model_12s”.* FROM “my_model_12s” WHERE “my_model_12s”.“my_model_10_id” = 123 CACHE (0.0ms) SELECT “my_model_10s”.* FROM “my_model_10s” WHERE “my_model_10s”.“id” = 123 LIMIT 1 CACHE (0.0ms) SELECT “my_model_11s”.* FROM “my_model_11s” WHERE “my_model_11s”.“my_model_10_id” = 123 CACHE (0.0ms) SELECT “my_model_12s”.* FROM “my_model_12s” WHERE “my_model_12s”.“my_model_10_id” = 123 CACHE (0.0ms) SELECT “my_model_10s”.* FROM “my_model_10s” WHERE “my_model_10s”.“id” = 123 LIMIT 1 CACHE (0.0ms) SELECT “my_model_11s”.* FROM “my_model_11s” WHERE “my_model_11s”.“my_model_10_id” = 123 CACHE (0.0ms) SELECT “my_model_12s”.* FROM “my_model_12s” WHERE “my_model_12s”.“my_model_10_id” = 123 CACHE (0.0ms) SELECT “my_model_10s”.* FROM “my_model_10s” WHERE “my_model_10s”.“id” = 123 LIMIT 1 CACHE (0.0ms) SELECT “my_model_11s”.* FROM “my_model_11s” WHERE “my_model_11s”.“my_model_10_id” = 123 CACHE (0.0ms) SELECT “my_model_12s”.* FROM “my_model_12s” WHERE “my_model_12s”.“my_model_10_id” = 123 Completed 500 Internal Server Error in 824ms
SystemStackError (stack level too deep): actionpack (3.2.8) lib/action_dispatch/middleware/reloader.rb:70
Rendered /path/to/ruby-1.9.3-p194@my_project/gems/actionpack-3.2.8/lib/action_dispatch/middleware/templates/rescues/_trace.erb (1.0ms) Rendered /path/to/ruby-1.9.3-p194@my_project/gems/actionpack-3.2.8/lib/action_dispatch/middleware/templates/rescues/_request_and_response.erb (0.8ms) Rendered /path/to/ruby-1.9.3-p194@my_project/gems/actionpack-3.2.8/lib/action_dispatch/middleware/templates/rescues/diagnostics.erb within rescues/layout (10.6ms)
So, I thought I’d look into how we are supposed to define associations and subassociations, etc.'s serializers in a single serializer or at least be able to define a different serializer type in the definition of the association in the serializer.
I see some mention of polymorphic in the code and this discussion of a pull request between Jose and Adam: https://github.com/josevalim/active_model_serializers/pull/24
Wondering what the best way to attack this is, and whether any of this is stuff others will run into/whether avoiding circular attributes is something that should be a serializer responsiblity other than the existing circular reference checking that happens already (does it only just check for back reference as I remember seeing vs. keeping track of previously output object_ids? I had to do the latter to avoid them in a previous version of restful_json when I was mutilating as_json)?
(Apologies for my continued ineptitude.)