MultiPoco queries may fail after a database schema change

[TomTondeur]

I bumped into an unfortunate interaction between the "multi poco" functionality and the use of wildcards in select statements.

As I understand it, when a query is run using PetaPoco, it generate some IL to efficiently store the query results. This generated IL is then cached, so that it can be re-used when the same query is run again later. The generated IL makes assumptions about the columns returned by the query, so the "offset" and "count" of columns are used in the key of these cached IL poco factories.

When using multi-poco queries, a wrapper "multi poco factory" is created and cached, which calls into the individual poco factories described above. However, as it stands, the "multi poco factory" cache key does not include column count.

Because of this, an inappropriate poco factory may be used when a multi-poco query is run if the new resulting set of columns is different from the first run. Here's an example:

SELECT *
FROM Orders o
JOIN People p ON p.Id = o.PersonId

ALTER TABLE Orders ADD SomeRandomColumn INT NULL

SELECT *
FROM Orders o
JOIN People p ON p.Id = o.PersonId

When the second query is run with the poco factories generated by the first, their split points will be incorrect, so fields can get parsed into the wrong poco, or fields may be dropped entirely.