There is a StackOverflow question on this located here (we upgraded from 4.0.39 to 4.5.6):
Issue is probably similar to Postgres String Arrays Broken
Gist of code showing issue using NUnit
However the main difference is that none of our models contain or use the array fields and the models are not populated.
SELECT *, array_to_json(my_array) AS my_json. In otherwords our tables and views contain the array fields and they are returned because of the
SELECT * however they are not contained in Models as we use the json version
It would be a significant undertaking to go thru all the queries and explicitly name each field that we want when there is typcially only 1 or 2 fields that would contain an array field which is not used in the model.
So is it possible if the array field isn't in the model to skip the array field(s) and populate the other fields by default? Because right now all fields are populated with null or default values, unless the array is NULL, then it populates the model.
For the curious, the reason why we use arrays instead of json was when we were evaluating Postgres 9.3 (when json was first available) json performance was terrible and queries took longer. A simple switch to arrays alleviated that issue and increased performance. I'm unsure if 9.6+ has fixed that issue or if jsonb would be better.
The Exception raised in the 2nd test is the use of
array_agg() which Npgsql doesn't support and throws
The field 'color_array' has a type currently unknown to Npgsql (OID 101487) when trying to read it from the data reader in a batch with
GetValues() which is the optimal way to fetch a dataset from an ADO.NET Data Reader.
I've added a fallback in this commit where if
GetValues() fails it will fallback to read from the DataReader individually which will resolve the issue in the tests. It logs a warning to indicate that there was an Exception trying to call the batched
GetValues() API and instead tries to falling back to individual column fetches.
You can avoid using the optimized
GetValues() altogether by configuring it to use the Deoptimized code path with:
OrmLiteConfig.DeoptimizeReader = true;
Which will avoid attempting to use
GetValues() and avoid its Exception.
The fallback is available from v4.5.7 that's now available on MyGet.
Thanks! We haven't finished testing, but so far so good. On a side note, when I was researching about the issue this morning I came across this Npgsql Issue 1324. Your committed fix should also avoid the issue of postgres infinite dates in DateTime values as that would have been the next issue we found.
I quoted below and bolded the interesting information from that Npgsql issue that
GetValues() should be avoided. It is possible that he is talking in a specific context of having to get an unknown type and not in general usage. Thought I should point that out if it does matter.
If your application needs values not covered by DateTime (e.g.
infinity), just use NpgsqlDateTime by calling
GetProviderSpecificValue(), or even better, GetFieldValue. This is a
much better option than having an inconsistent API that sometimes
returns DateTime and sometimes NpgsqlDateTime. True, you can't use
GetValues() to get all values at once, but you have all the alternatives
On a side note, GetValues(), GetValue() and GetProviderSpecificValue() should be avoided in many cases anyway, since they box your values (as opposed to GetFieldValue).
GetValues() to provide better performance which is why we've switched to using it by default.