Message format - three element vs four element tuples

[cheerfulstoic]

There was some discussion in this issue about three element vs four element tuples in the messages that EctoWatch sends. The current version:

def handle_info({:inserted, MyApp.Accounts.User, primary_key_value, _extra_columns}, socket) do

The proposal:

def handle_info({:inserted, MyApp.Accounts.User, %{primary_key: primary_key_value, ...}}, socket) do

I'm potentially interested in this change, though I remember having a conversation with my colleague @CoderDennis and I believe he gave a reason which I liked for going with the four-element tuple (I think maybe something having to do with how code might break if you changed the watcher). I wanted to ask him to chime.

[barrelltech]

I like this reasoning, one very loose argument against it would be:

Let's say I have have some different subscriptions set up. These could be all comments in general, where I want to update some counter, then all comments with a specific post id, and I want to show those in a channel viewing that specific post_id.

Listening in the channel for all of the updates:

def handle_info({:inserted, MyApp.Post.Comment, _, _})

is indistinguishable from listening to the specific post updates:

def handle_info({:inserted, MyApp.Post.Comment, id, _})

You would have to do something like

def handle_info({:inserted, MyApp.Post.Comment, id, _}, socket) do 
  if uuid == socket.assigns.post_id do
    specific_action()
  end
  general_action
end

It's not a dealbreaker or a massive issue, quite an edge case, and entirely down to personal preference. I could see someone making the case why it's actually preferred to do this. But I would prefer having two seperate actions personally.

PS: in #7, my idea for events-as-config could also support nil values if you wanted to maintain arity equivalece, so

watchers: [
  {:inserted, MyApp.Blog.Comment, nil, nil}.
  {:inserted, MyApp.Blog.Comment, :uuid, [:post_id]}
]

Could be used to generate Comment level and Comment.uuid + post_id events with the same arity :)

[CoderDennis]

I know I didn't have a strong opinion either way, but I don't remember for sure what I said. It was probably along the lines of only putting the optional stuff in the map and always including the primary key as an element of the tuple. But now I don't even know if that's a good argument because a table might not have a primary key or could have a composite primary key.

[cheerfulstoic]

👍 Thanks!

I was looking up if it's possible to have a schema without a primary key and it seems like it isn't... You can have a many_to_many table without a primary key, but not something that has a schema. But yeah, of course you can have a primary key. You could still allow for a tuple with the elements of the primary key in the message, but honestly composite primary keys are one of the biggest things convincing me that it probably makes sense to not make the primary key a separate element in the message tuple