#RubyOnRails - 15 July 2019
« Back 1 day Forward 1 day »
[04:12:45] Norrin: I feel like my team is trying to do something silly. They want to make a string column with UUIDs in it instead of using the default id primary key
[04:13:34] Norrin: they think it makes sense in case tables ever move, the UUIDs will be the same but the default id column would not?
[04:15:12] dgs: you can't change them ... and perhaps what you want now, but who's to say that will hold true forever
[04:16:34] Norrin: ok. I'd say that UUIDs fit that description. meaningless other than them being unique
[04:16:44] dgs: not to mention it's breaks convention / is non standard, which can be a pain with ORM's and needs to be managed
[04:18:38] dgs: but if i was starting something from scratch, there would need to be a fairly compelling reason not to go with the standard PK + sequence
[04:18:39] Norrin: so their fear is that default id's might change if some records were deleted or the table moved & altered in some way. Does that sound realistic?
[09:30:24] Norrin: this guide is saying that db constraints on uniqueness cannot be done on multi column indexes. https://guides.rubyonrails.org/active_record_validations.html#uniqueness
[09:30:48] Norrin: https://stackoverflow.com/questions/1449459/how-do-i-make-a-column-unique-and-index-it-in-a-ruby-on-rails-migration/1449466#1449466
[12:35:12] Sylario: ZAJDAN: Devise only give you authentication. For authorization, you need to do it on your own
[12:38:22] Sylario: ZAJDAN: I use pundit because it allow to modify the scope based on authorization, but it's heavier than cancancan to implement
[12:47:31] Norrin: on https://guides.rubyonrails.org/association_basics.html there is a phrase that reads: "Rails will not create foreign key columns for you. You need to explicitly define them as part of your migrations."
[12:48:23] Norrin: It's rather confusing. It's kind of not true. if you list a reference in a migration it does create the column for you....
[13:00:43] Sylario: devise allow you to know that visitor V is tied to user account N. cancancan will check that user N can do action Foo or not.
[13:15:52] Norrin: how can https://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/SchemaStatements.html#method-i-add_reference be updated so that it mentions that the hash passed to foreign_key is forwarded to add_foreign_key, and therefore that the hash documentation is listed under add_foreign_key ?
[17:07:27] jamaio: Hello. Is it a good idea to isolate all logic that might be in a controller into a service object?
[17:08:27] jamaio: Like, if I have code that calls the model in the controller is that something I should avoid?
[17:16:11] havenwood: jamaio: Have an example of the logic you're talking about? Is the app already using service objects?
[17:18:11] havenwood: jamaio: I think _all logic_ is too broad of a generality, since controller logic to fetch or save from the model is appropriate for the controller.
[17:18:24] jamaio: havenwood: not using any service objects yet. mostly just crud on the different resource types in my app with a few third-party api calls
[17:18:25] havenwood: jamaio: "A controller can thus be thought of as a middleman between models and views."
[17:19:31] havenwood: jamaio: It's fine if the logic in the controller isn't about getting the data it needs from a model to serve up in a view.
[17:20:22] jamaio: sorry, i think i'm confused by "isn't about". you're saying it is or is not okay for that logic to be in the controller?
[17:22:10] havenwood: jamaio: Be suspicious of non-controller logic in the controller! If there's a recipe for french toast in your controller, or internal logic about using an API, or that type of thing, it probably doesn't belong there. If there's logic about which model info needs to be passed to the view, that's what controllers are for.
[17:25:00] havenwood: jamaio: Check out, for example, the types of things in controllers/ versus services/ here: https://github.com/discourse/discourse/tree/master/app
[17:25:36] jamaio: thanks, that really clears up the thinking for me. i like the way you put it. so if i need to kick off a process in the request, but it's response is not required for the view, maybe use a service or a job- otherwise don't be afraid to grab data from the model and pass it to the view right in the controller. sound good?
[17:25:52] havenwood: Also, TIMTOWTDI. I'd suggest sticking with Rails convention as close as you can until you have a good reason to go off the Rails.
[17:27:54] jamaio: perfect! it seems like some of the more philosophical articles on service objects suggest wrapping any business logic inside them, so you end up with tiny controllers. not sure how i feel about being that strict. the argument of code being able to test is interesting
[17:29:48] jamaio: i guess really that's the best argument i've seen, being easier to test. but is it really that hard to test controllers directly?
[17:44:24] havenwood: jamaio: If the view doesn't end up with the right data from the model, the controllers aren't working. Rails has actually backed a bit away from tons of controller tests. There were some interesting articles on why.
[17:45:55] jamaio: havenwood: oh so you're saying that typically one doesn't actually write tests for the controllers?
[17:47:53] havenwood: jamaio: I said that badly. I write functional tests for controllers. There were some helper functions for going deeper with controller tests that were removed, because they were seen as testing internals and not useful. You can use them as a gem now. https://guides.rubyonrails.org/testing.html#functional-tests-for-your-controllers
[17:48:28] havenwood: jamaio: I just meant #assigns, #assert_template, etc: https://github.com/rails/rails-controller-testing
[17:48:59] havenwood: jamaio: https://blog.bigbinary.com/2016/04/19/changes-to-test-controllers-in-rails-5.html#deprecation-of-assigns-and-assert_template-in-controller-tests
[17:49:37] jamaio: ah i see. so you want to write integration tests, not unit tests for controllers nowadays
[17:50:11] havenwood: "The idea behind the removal of these methods is that instance variables and which template is rendered in a controller action are internals of a controller, and controller tests should not care about them."