[Mono-list] Bug (?) in SqliteDataReader

[Nikki Locke]

Joshua Tauberer wrote:
> So, putting it all together from all of your ideas, maybe the best thing 
> to do is: 
>   Any DATE/DATETIME column values are forced to be DateTimes. 
>   Anything that can't be converted to a DateTime is returned as null 
> (any double values, invalid long values, and unparseable strings), 
> avoiding casting exceptions later on. 
>   The column type in GetSchemaTable is returned as DateTime. 
>   All of this (including the existing DateTime conversion) can be 
> turned off via the connection string, ensuring that there is a way to 
> read any database. 
>  
> This would be a breaking change in so far as double and unparseable 
> string values in DATETIME columns will be reported as null, rather than 
> being accessible through the SqliteDataReader. 
>  
> *But* if the DateTime parsing issue is a bug and is fixed, none of this 
> is really necessary except as a possible performance improvement to 
> avoid parsing DateTimes twice (once in SqliteDataReader, once in user 
> code)... Does it make sense to attack this from that angle instead, 
> rather than making a breaking change to the data adapter?

I do think it should be more consistent than it is (have you any thoughts on my 
other comment about inserting DateTimes as parameters?).

I think that, in order to avoid breaking existing code, the default should be much 
as it is now, EXCEPT do not convert strings to DateTimes in ReadpVm 
(SqliteDataReader, about line 188). That would stop it giving an exception when a 
string is inserted in a DateTime. It would also prevent the DateTime getting 
converted back into a string by the DataTable (which is what makes the original 
value unrecoverable).

If you have the time and inclination, you could accept an extra parameter to the 
connection string which would turn ON the behaviour you suggest above.

How does that sound?

-- 
Nikki Locke, Trumphurst Ltd.      PC & Unix consultancy & programming
http://www.trumphurst.com/