Suggestion: This feels more like a "fake" than a "mock".

Note: Using limit/offset will get increasingly more slow as the table grows and you paginate further. First page will usually remain fast though.

Fine for now, though. Just raising awareness.

Considering we have both connect and disconnect enums andtype isnot part of this conflict handling, it suggests to me there is some gap in the logic. Considering connect/disconnect both share the same connection ID, we'll never write the disconnect but upsert the connect with close time and reason.

Either writing two entries, or doing a upsert, might make sense. But I think we have to ask what are we trying to achieve here and how are we looking to display the data?

My take as a user would be that I want to see two separate entries in the log, appearing in their chronological order. When viewing the connect, it would be an additional nice bonus to be able to see when the disconnect happened, and vice-versa that could simply be achieved by applying the connection ID as search filter.

EDIT: Correction, I was referring to "connection_action" (connect/disconnect), not "connection_type". But upon closer inspection that database type is not even used so it should probably be removed if not intended to be used.

That said, I want to clarify that I'm not concerned with whether or not we write two entries or upsert one, but in the latter case I do think we should make sure to "explode" the data when queried so that we can show the events in their chronological order.