Fork me on GitHub
Jakub Holý (HolyJak)13:10:42

@seancorfield Out of curiosity, what is the reason that (extend-protocol Executable DataSource ... implements the methods from scratch instead of just delegating to the Connection impl., i.e. (-execute [ds sql-params opts] (with-open [conn (get-connection ds)]) (-execute conn sql-params opts)) ? Does the double dispatch here (-> DataSource -> Connection) have visible impact on performance? Thank you!


-execute is plan so it should return an IReduceInit -- it should not get a connection immediately.


The implementations are all standalone. Partly for performance but partly for maintenance -- having the code inline means that if I'm considering the three implementations for a single protocol, I have all the code right there on a single screen and I don't have to drill into some other definition to think through the code.

👍 1
Jakub Holý (HolyJak)17:10:46

Though the extend-protocol p/Executable has impl. for both D.S. and Connection at the same place so if one reused the other you still would only need to scroll up a few lines?


Each set of implementations is about one screenful of code so it would end up being more than "scroll[ing] up a few lines". And performance matters (I went back and forth a lot with Tommi Reiman while next.jdbc was being developed).

👍 1

That's why runtime testing of types/protocols is off the table, BTW, for performance-critical functions (`execute-batch!` is not considered p/c there because the batched DB activity is assumed to completely overwhelm the cost of calling it and you don't tend to call it repeatedly: you call it "once" with large batches of data -- but execute! etc are p/c).


(and I really don't want to extend those protocols to Object!)