#elixir-lang - 24 April 2019
« Back 1 day Forward 1 day »
[06:53:39] mdbm_: 03:42:17.772 [error] Loading of c:/data/projects/elixir/issues/_build/dev/lib/issues/ebin/Elixir.Issues.GitHubIssues.beam failed: :badfile
[07:01:50] josevalim: mdbm_: you can always try removing the _build directory and running `mix compile` again
[09:37:57] ctp: Hi folks. I still struggle with merging two maps. Does someone has a hint for me? https://stackoverflow.com/questions/55826922/merging-elixir-maps
[09:51:02] ctp: Hm, OK, I see this could help somehow, took a look at merge/3 yesterday, but how to actually concatenate those 2 lists just for the key c?
[14:40:34] drewolson: is there a correct way to indicate "i don't intend to implement this protocol for other built-in types" that makes dialyzer happy?
[15:00:10] linduxed: for Ecto, i've noticed that one can make a call to the Repo.transaction/2 callback without the last opts argument, essentially making it work like a transaction/1 (where the signature would have had "opts \\ "). this is not documented here https://hexdocs.pm/ecto/Ecto.Repo.html#c:transaction/2
[15:40:01] gamache: linduxed: I think you are getting confused between the Ecto.Repo.transaction/2 callback spec, and its usage within an implementation of that behaviour like MyApp.Repo
[15:41:07] linduxed: gamache: right, i'm referring to how it's used, like MyApp.Repo.transaction(fn -> :foo end)
[15:41:12] gamache: if you're implementing the behaviour, all you need to do is write the two-argument version, and end users can use the one-argument version automatically thanks to some plumbing the Ecto devs built
[15:46:29] gamache: it's in the `defmacro __using__` part of https://github.com/elixir-ecto/ecto/blob/v3.1.2/lib/ecto/repo.ex
[19:31:32] nageV_: I want to turn off discarding altogether for some Flow instrumentation I'm doing (tracking the number of items going through my Flow over time)
[21:06:10] Randyr: How do you people go about separating your web logic from your business logic in Phoenix contexts? I often end up with functions in my context that are still aware of things like pagination, preloads, etc. because these values are dependant on the controller.
[21:14:07] Randyr: mk: The context still needs to understand the pagination scheme used in the controller, which relationships the user requested and should be preloaded, which filters should be applied, etc
[21:16:29] Randyr: mk: I do pass those as arguments, but it does mean that the contexts are aware of the web layer, which ideally it shouldn't (in my opinion).
[21:17:05] Randyr: Similarly, my controller should now be aware of the possible relationships on the schema that it might preload.
[21:19:30] Randyr: mk: Yes, I agree, but take for example a JSON API. I can have `/users?include=posts&filter[name]=john`. I generally validate this before I pass it on onto the contexts.
[21:19:42] mk: Randyr: controllers usually authenticate, decode, and pass the values to the context/helper/service
[21:21:19] mk: Randyr: your controller then would call the validator, then if successful call the context
[21:23:13] Randyr: The validation of the query params like above happen in a plug for now, which is fine. But take for example the `?include=posts`. Posts in this case is a relationship on users. Since the validation happens in the controller, that means the controller is aware of the db relations.
[21:49:25] starbelly: controller -> context -> pure data context -> back to context -> on to persistance, whatever
[21:50:33] starbelly: pure data context would no nothing except data in -> out, and contain your business rules
[21:51:10] starbelly: ACTION also uses the word context loosely and doesn't subscribe to the term DDD