...but at least it's done.

In the original, memory based, version of tks queryies returned answers; and answers had a method getRowCount() which did exactly that. The problem with that is that memory dosn't scale as well as disk does. So we moved to a disk backed architecture. Now when you are memory based, you want to release your memory as soon as possible, so you want to resolve (and subsequently release) any intermediate results immediately. Once you are backed by disk, you have much better uses for memory than storing an answer the user isn't using yet, so you want to evaluate your query as lazilly as possible. Hence Kowari/TKS has this concept of a Tuples, which is a thunked, localised, intermediate result. This gets wrapped in an Answer object, which is returned to the user, and resolves the Tuples by need.

The problem is that calculating an accurate row count becomes a potentially expensive operation; you can generally only afford an upper-bound instead. So unfortunately while the semantics changed, the name stayed the same, to the general confusion of all.

Subsequentely I have spent the past 2.5 days reverting the semantics, and introducing new methods to access the upper-bound (and cardinality). Tedious work, but at least it's done.

Now on to getting resolvers to play nicely with transactions.