I’m working on an ORM that allows you to query multiple databases — the idea being that read queries go to replicas and write queries go to the primary. I also want to make sure that you can read your own writes to avoid race conditions where you query the replica before a write has been replicated, but I can’t tell from the logs which database is being queried since DB only configures a single logger.
I also think it’d be useful to aggregate logs to see what the split is between reads and writes.
In this case, would it make sense not to use DB::Log and instead set up my own loggers for reads vs writes or is there a way to distinguish them better with what already exists?
The protected def emit_log(args : Enumerable) method can be overriden and the @connection is accessible in the statement command. I’m not sure if that is enough to get the information you need. Worst case you can defer the logging of the statement to the connection object maybe. Does that helps?
This is kinda what I’m looking for:
query.get_things
# TIMESTAMP -- db.replica -- query: "select ...", args: ...
query.delete_things
# TIMESTAMP -- db.primary -- query: "delete ...", args: ...
query.get_things_again
# TIMESTAMP -- db.primary -- query: "select ...", args: ...
Would I need to do my logging at the ORM layer (instead of relying on DB::Log) in order to make something like this work?