Following all events

[cheerfulstoic]

👋 Hey, sorry I haven't gotten a chance to check out this project until now!

This is maybe more of a discussion than an issue, but I see you have a all_events and subscribe_all functions. I did actually consider a couple of options for ecto_watch:

• Allowing people to specify {User, [:inserted, :updated, :deleted]} as watchers and EctoWatch.subscribe({User, [:inserted, :updated, :deleted]}) for subscribing
• Allowing people to specify {User, :all} as watchers and EctoWatch.subscribe({User, :all}) for subscribing

In the end I decided (at least for the time being) that I would require that people be more explicit about what they're setting up and subscribing to. Especially for the configuration of the watchers it also felt like it was good to stick with requiring that there be one entry in the watchers list for every watcher because each one ends up creating a supervised GenServer.

But this all be a bit unnecessary. Maybe it would be good to allow either a list of events or the :all atom. Either way since you're creating a wrapper around ecto_watch, it could be good to follow its conventions to be less confusing to users of your project.

I'd be happy to hear your thoughts on the above two options.

[cheerfulstoic]

I've been looking at the code a bit more and I'm starting to get how all_events creates watchers for associations too.

I'm thinking about when ecto_watch was mentioned on the Thinking Elixir podcast and remembering something that they said: that they liked how you could see what watchers were setup inside of the application.ex. It wasn't something that I thought about before that, but I realized that it's potentially a nice advantage because rather than having the triggers/functions being in migrations (or worse, setup outside of the application), there is a very clear declaration of what is being setup in the database inside of the application.ex. But auto-generating associations, we lose that visibility some.

I come from 12 years in the Ruby world, and it's been my impression that the Elixir/Phoenix community has taken a lot of inspiration from Ruby, but it has also tried to pull back from the "magic" that a lot of people would complain about in Ruby libraries. Generally this involves making your "wiring" more explicit. Some examples:

• ecto using the "repository" pattern rather than the "active record" pattern
• The MyAppWeb module in Phoenix giving a place for the various parts of Phoenix
• The core_components.ex file which is setup with new Phoenix apps
• Libraries requiring that people copy/paste configs from a README
• mix phx.gen.auth which is a response to José seeing how complex the devise library (which he created) had gotten (blog post)

So if there is any sort of magic like what you've got going on, it's worth thinking very carefully about if users will understand it (I'm honestly still wrapping my head around ecto_sync and I've been staring at the code for an hour). If you do have magic, it becomes even more important to think about the API (I've re-written ecto_watch at least once, and I've iterated on the API quite a bit)

[Zurga]

Thanks for taking the time to look at the code and giving me feedback, it is very much appreciated! I think `ecto_watch` fills a gap in the ecosystem, but I find its use a bit clunky at the moment. I have never used Ruby, Python was my language before Elixir. You are right in the notion that magic can be counter-productive and that the API needs to be very clear, concise and consistent. `ecto_sync` scratches at least two itches I have: 1. being able to subscribe to events on associations, 2. provide a caching layer in between `ecto_watch` and the subscribers. The main use cases I have in mind for `ecto_sync` are: - updating rows that are changed by other processes, including when associations change; - updating possible associations for a given row, for example when inserting. After thinking about the project for a weekend, it could be made a lot simpler if `ecto_watch` implemented an adapter pattern for the subscribing/dispatching/unsubscribing. It would allow users to subscribe with a Registry for example, or to create an adapter that adds a `ref` for sent events to aid cache key creation (`ecto_sync` uses both of the aforementioned). The functions you mention are helpers, but the `EctoSync.EventHandler` implements a caching mechanism similarly to the notes you created about a caching GenServer. On purpose, the function `all_events` can take a list of watchers as the first argument. I think that being able to specify the watchers in `ecto_watch` with a list and the `:all` atom would be a good ergonomic change. Maybe I should rename the `all_events` function to `assoc_events`. To me, the usefulness lies more in the ability to generate watchers for associations. You are right that we lose some of the visibility on which watchers are generated for the associations, but I believe that the ergonomic value it provides is worth it. It uses the same amount of magic as `Ecto.Repo.preload` to determine which `extra_columns` to provide, and supports creating watchers for ManyToMany associations (even the ones without a `join_through` module. All watchers are de-duplicated in the end. If `ecto_watch` would allow an `:assocs` option in the watcher specification tuple, this function could be removed. What is your opinion on supporting this? The `subscribe_all` function is a bit of a misnomer when put alongside of `all_events`. It is supposed to subscribe the process to all events on the provided row, its preloaded rows, and associations (nested or not). I am still a bit on the fence whether to keep this function or not. Perhaps a single `subscribe` function that allows users to specify which associations to subscribe to would be better. Something like: ```elixir posts = Posts.list_posts(preload: [comments: [:author]]) subscribe(posts, assocs: [:comments]) ``` This would subscribe the process to: - changes on the posts [:updated, :deleted], - changes for the preloaded comments [:updated, :deleted], - insertion of a new comment for the loaded posts. Similarly to the `all_events` function, it could be nice to add support for subscribing to associations in `ecto_watch`. Op za 8 mrt 2025 om 16:53 schreef Brian Underwood ***@***.***

…

: I've been looking at the code a bit more and I'm starting to get how all_events creates watchers for associations too. I'm thinking about when ecto_watch was mentioned on the Thinking Elixir podcast <https://podcast.thinkingelixir.com/211> and remembering something that they said: that they liked how you could see what watchers were setup inside of the application.ex. It wasn't something that I thought about before that, but I realized that it's potentially a nice advantage because rather than having the triggers/functions being in migrations (or worse, setup outside of the application), there is a very clear declaration of what is being setup in the database inside of the application.ex. But auto-generating associations, we lose that visibility some. I come from 12 years in the Ruby world, and it's been my impression that the Elixir/Phoenix community has taken a lot of inspiration from Ruby, but it has also tried to pull back from the "magic" that a lot of people would complain about in Ruby libraries. Generally this involves making your "wiring" more explicit. Some examples: - ecto using the "repository" pattern rather than the "active record" pattern - The MyAppWeb module in Phoenix giving a place for the various parts of Phoenix - The core_components.ex file which is setup with new Phoenix apps - Libraries requiring that people copy/paste configs from a README - mix phx.gen.auth which is a response to José seeing how complex the devise library (which he created) had gotten (blog post <https://dashbit.co/blog/a-new-authentication-solution-for-phoenix>) So if there is any sort of magic like what you've got going on, it's worth thinking very carefully about if users will understand it (I'm honestly still wrapping my head around ecto_sync and I've been staring at the code for an hour). If you do have magic, it becomes even more important to think about the API (I've re-written ecto_watch at least once, and I've iterated on the API quite a bit) — Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBBRQUMRKC4UJ2DA6K2NDD2TMG6ZAVCNFSM6AAAAABYTEAUD6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBYGM3DKMZRGU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> [image: cheerfulstoic]*cheerfulstoic* left a comment (Zurga/ecto_sync#6) <#6 (comment)> I've been looking at the code a bit more and I'm starting to get how all_events creates watchers for associations too. I'm thinking about when ecto_watch was mentioned on the Thinking Elixir podcast <https://podcast.thinkingelixir.com/211> and remembering something that they said: that they liked how you could see what watchers were setup inside of the application.ex. It wasn't something that I thought about before that, but I realized that it's potentially a nice advantage because rather than having the triggers/functions being in migrations (or worse, setup outside of the application), there is a very clear declaration of what is being setup in the database inside of the application.ex. But auto-generating associations, we lose that visibility some. I come from 12 years in the Ruby world, and it's been my impression that the Elixir/Phoenix community has taken a lot of inspiration from Ruby, but it has also tried to pull back from the "magic" that a lot of people would complain about in Ruby libraries. Generally this involves making your "wiring" more explicit. Some examples: - ecto using the "repository" pattern rather than the "active record" pattern - The MyAppWeb module in Phoenix giving a place for the various parts of Phoenix - The core_components.ex file which is setup with new Phoenix apps - Libraries requiring that people copy/paste configs from a README - mix phx.gen.auth which is a response to José seeing how complex the devise library (which he created) had gotten (blog post <https://dashbit.co/blog/a-new-authentication-solution-for-phoenix>) So if there is any sort of magic like what you've got going on, it's worth thinking very carefully about if users will understand it (I'm honestly still wrapping my head around ecto_sync and I've been staring at the code for an hour). If you do have magic, it becomes even more important to think about the API (I've re-written ecto_watch at least once, and I've iterated on the API quite a bit) — Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBBRQUMRKC4UJ2DA6K2NDD2TMG6ZAVCNFSM6AAAAABYTEAUD6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBYGM3DKMZRGU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Zurga]

I have created an implementation of the adapter style pattern here: Zurga/ecto_watch#1