On 2014/07/14 17:50, Bruce Cowan wrote:
RSmith wrote:
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. If you need the returned names to be exactly something
specific, then you need to use the "AS"
directive. I find it hard to imagine that ServiceStack.OrmLite does not know
this - but it is possible. This question would
probably get more useful replies on an OrmLite forum.
OrmLite is very flexible in what it will accept for the column names in the DbDataReader. In the failing case
the column names in the reader are all the same and they are all "view-name". That is clearly not
sensible as there is no way to retrieve data from the reader by column name. Requiring an "AS"
directive to select columns from a view when that is not required to select columns from a table seems
basically incorrect to me. At the very least it is inconsistent. Then there is the output from the SQLite3
command-line shell which also prints the headers as all "view-name" for the failing case.
Hi Bruce,
I understand your concern and request and your need for it. Phrases like "clearly not sensible" and "seems incorrect to me"
unfortunately holds no water, and why is it that ormlite is very flexible but cannot read or ask for coulmn names specifically? or
follow clear schemata available through standard queries in all RDBMSes? Also from a later email, the fact that most other Data
readers do it differently is a quirk of chance, not a standard and not a requirement. This is like ordering vehicles from an
english manufacturer without specifying left-hand drive, and then being confused why they all come with right-hand drive, saying
everyone else makes left-hand drive cars. It isn't a rule or a requirement, even if it seems non-sensible, even if Microsoft does it
another way, it still isn't a "fault" of the manufacturer.
Now, having said all the above, it is a silly quirk, and knowing Dan and Richard and the other Devs' dedication, they probably
already fixed this in some next trunk and will post it soon - but it does not detract from the very important fact that all the "but
it's silly like this" arguments are missing: Please understand, it is not a standard, it is not a requirement, you have a system
that expects it to be so and that system is in danger of breaking in the future because this may change, even for the other engines.
Are you really comfortable to derive a system based upon an assumption that is not solid? That is the real point, even if the quirk
is ironed out. At least raise the awareness with ormlite's people that they should fix this.
Btw: Microsoft's documentation (much as I love them) is the furthest possible thing from a viable standard that anyone can site. It
is hard to find a less consistent and convoluted view of things, but kudos to them for being complete - any single Windows API or
function spec is more likely bloated than undocumented.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
