On 2014/07/13 22:45, Clemens Ladisch wrote:
RSmith wrote:
On 2014/07/11 17:26, Bruce Cowan wrote:
When you select columns from a view, the (ADO.NET) DbDataReader that is
returned from the execute call does not contain sensible column names
There is no contract of which column names should be returned, no
"incorrect" headers and no guarantee, and no obligation from the
standard or any other requirement.
But these particular column names do not look as if they were anything
but as bug:
sqlite> select "TestView"."id", "TestView"."data2" from TestView;
TestView TestView
---------- ----------
1 Miranda
Hi Clemens,
I'm not sure what you mean. I think you are saying that the specific case feels like it is buggy and the SQL engine should rather
return the second part of the column name as it will in some other circumstances? If this is what you are saying, I can agree, it
would be nice if it behaves the same.
There is an important difference between "would be nice if..." and "it IS a bug" though. It is NOT a bug, it is not documented to
behave differently, nor required to. Making it behave the same would be nice, but it can't be a requirement, and much more
importantly, any system that you develop or use MUST necessarily NOT expect it to work that specific way for future-proofing or just
in general compliance.
So if we want a ticket to ask an adjustment of this quirk, I don't see why not,
would be nice - but the OP stated:
"This problem makes SQLite views completely unusable with ServiceStack.OrmLite
version 4.0.23 or newer"
which sounds a lot like it is perceived to be an SQLite problem, but it is not an SQLite problem, it is an OrmLite v4.0.23 problem
(which might be "helped" by the above fix, but should not ever be expected to work that way). In this regard I would urge the
OrmLite people foremost to adjust their system to be standard and compliant, and as an aside maybe patch the SQLite quirk as a
matter of luxury, not necessity.
I might be a bit over-jittery too, but many years finding problems in systems has made me allergic to the expectation of behaviour
that is not explicitly documented, I almost prefer it to work wrong so it highlights the issue during the dev cycle already. I only
ever use strict mode SQL in other engines, and others have been asking on this forum for a "Strict" mode in SQLite, which I think
would be even more useful than fixing a quirk to comply to a non-required non-documented behaviour.
But I'll roll with whatever induces euphoria :)
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
