> Can't you just store the struct as a blob and be done with it?
No, I can't use a blob because there are other queries where I want individual
columns. Storing to and from a struct is only one part of the application.
Sorry, perhaps I should have specified that too.
> Why is 99 a 16-bit integer value and not, say, an 8-bit or a 32-bit one? How
> is SQLite supposed to know?
How would SQLite know if "99" is 16-bit, 8-bit, 32-bit, etc... using the CREATE
TABLE specified data types as a hint.
> sqlite3_column_bytes is really only meaningful for strings and blobs,
not for numbers.
Perhaps, but I know for SQLITE_INTEGER type it gives me either 1, 2, or 4 for
various inputs I've tried. It's just not always the same as the original value
used.
> In order to preserve it, you need some way to specify it first. How do you
> plan to do that?
Again, the data types specified in a CREATE TABLE statement can serve as a hint.
>> E.g.:
>>
>> CREATE TABLE test ( val1
INTEGER, val2 INT2, val3 INT1 ... );
>>
>> Here val1
is always 4-bytes, val2 is always 2 bytes, and val3 is
>>
always 1 byte.
> Well, if you want to invent a naming
convention like that, why don't you act on it yourself? Retrieve the
type name with sqlite3_column_decltype, handle it as you see fit.
That was just an example, not an actual table declaration for this app.
So, basically I either store everything as a blob and lose the ability to query
individual columns, or I have to rework a lot of existing code (the app uses
MySQL now) to work with SQLite's own nuances?
-- Kevin
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
