On Mon, Mar 29, 2010 at 02:01:42PM -0700, Kevin M. scratched on the wall:
> > 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.
Then store each field as a BLOB. That will preserve both size and
representation. You'll lose some of the format conversions, but that
doesn't sound like a big deal in your case. You might want to pick
a bit-ordering, however.
> > 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.
Yes, but your application will need to deal with that. SQLite's
column "types" are not really types, their hints to an affinity and
storage class.
Or you can use a datatype that includes a length, such as a BLOB.
> or I have to rework a lot of existing
> code (the app uses MySQL now) to work with SQLite's own nuances?
This is hardly an SQLite nuance. Although MySQL offers some
explicit integer sizes, many databases do not.
Database types are not C types. Any assumption otherwise is going to
get into trouble. In fact, SQLite matches standard C types more
than most databases.
If, for whatever reason, your struct/table creation and packing code
knows the length of each field, but the unpacking code does not, you
need to store that information somewhere. If you want to use a
datatype, such as BLOB that stores that info, fine. If you want to
use a column type with some type of app-specific encoding, fine.
Either way requires you to modify the unpacking code. I don't really
see the difference between something that queries a type size and
something that queries the column type and does a bit of parsing.
You also have the issue that most modern compilers will insert
padding, depending on the layout of the struct, but I assume you have
some way to deal with that. You're not always going to be able to
write a generic "unpack" function, however. Just like the packer, at
some point it will likely need to know about the structure it is
unpacking.
-j
--
Jay A. Kreibich < J A Y @ K R E I B I.C H >
"Our opponent is an alien starship packed with atomic bombs. We have
a protractor." "I'll go home and see if I can scrounge up a ruler
and a piece of string." --from Anathem by Neal Stephenson
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
