[Mono-list] Bug (?) in SqliteDataReader

[Joshua Tauberer]

Nikki Locke wrote:
> Joshua Tauberer wrote:
>> I don't think there should be a database that can't be read using any 
>> method, even if it wasn't created with Mono.Data.SqliteClient and even 
>> if it has crazy nonuniform data in columns. 
> 
> Well, it is currently possible (actually, easy) to write a data row using the 
> existing Mono.Data.SqliteClient library which cannot be read back!

True enough, though I guess what I mean is that I wouldn't want to make
this situation worse.

> Note also that storing an arbitrary integer in the DateTime field does not 
> result in a sensible value being returned - the integer has been converted to a 
> string, then passed through DateTime.Parse().ToString().

If you Fill a DataTable to get the data.

> The bug in DateTime.Parse which does not correctly parse the output of 
> DateTime.ToString in certain locales should also be fixed, but I have no idea 
> where to start with this one, as I haven't unravelled the maze of twisty code 
> which does the job. Suggestions welcome!

Start a separate thread for that to get some other peoples' attention. :)

> In a similar vein, it would be nice if Mono.Data.Sqlite had trivial subclasses 
> of all the public classes called "SQLite*" instead of "Sqlite*", thus making it 
> even more compatible with Finisar (without breaking any existing code).

That's not ugly at all!

Jonathan's suggestion sounds like a good idea:

> What about making SQLite type "safety" an optional feature, configured in
> the connection string, so that when enabled, the GetSchemaTable method
> returns the types asreported by SQLite, but by default (with a plain,
> standard connection string) it returns all columns as 'String'?

What I wish we could do would be to have all of the special DateTime
handling functionality dependent on the connection string, but that
would break how it works currently.

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?

-- 
- Joshua Tauberer

http://taubz.for.net

"Unfortunately, we're having this discussion. It's too bad,
because guess who listens to the discussion: the enemy."