From 91dda2cdae3f9e897a54fe21edf8467acae8aa0d Mon Sep 17 00:00:00 2001 From: Sean Corfield Date: Wed, 24 Mar 2021 23:45:54 -0700 Subject: [PATCH] Document stateful transduce issues: Fixes #149 --- doc/getting-started.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/getting-started.md b/doc/getting-started.md index 8294109..371cf68 100644 --- a/doc/getting-started.md +++ b/doc/getting-started.md @@ -372,6 +372,8 @@ user=> (plan/select! ds ["select * from invoice where customer_id = ?" 100]) ``` +> Note: you need to be careful when using stateful transducers, such as `partition-by`, when reducing over the result of `plan`. Since `plan` returns an `IReduceInit`, the resource management (around the `ResultSet`) only applies to the `reduce` operation: many stateful transducers have a completing function that will access elements of the result sequence -- and this will usually fail after the reduction has cleaned up the resources. This is an inherent problem with stateful transducers over resource-managing reductions with no good solution. + ## Datasources, Connections & Transactions In the examples above, we created a datasource and then passed it into each function call. When `next.jdbc` is given a datasource, it creates a `java.sql.Connection` from it, uses it for the SQL operation (by creating and populating a `java.sql.PreparedStatement` from the connection and the SQL string and parameters passed in), and then closes it. If you're not using a connection pooling datasource (see below), that can be quite an overhead: setting up database connections to remote servers is not cheap!