Reads like good common sense to me :-). I mentioned Base64 and Hex as a
possibility if TEXT type were to be used. As you so clearly point out
they would be pointless if a BLOB is used.
I also appreciate your comments about "horses for courses". If you are
just storing a JPEG image why do it inefficiently in a database unless
you have need for the facilities supplied by the database? Simple is
always better. The idea of storing simple non-variant computational
data structures in XML is bizarre.
Teg wrote:
Hello John,
You guys are both going off in you own directions and arguing
something that's really an unimportant implementation detail.
Serialization's a wonderful thing, if you need it. It's nothing more
than a protocol for storing, saving, transmitting something in a
format that can be re-constituted on the the other side by a reader.
It's useful, if you need it and solves problems some implementations
have.
As for using base64 or hex encodings, why bother? SQLite is
perfectly happy with binary insertions using the newer parameterized
SQL compiling. I insert naked JPG files all day long with no encoding.
Inserting binary though doesn't solve the basic problem with
alignment and struct packing (which is only an issue in some cases),
serialization does solve this problem but, it may be a non-issue
depending on your implementation/CPU.
When your only tool is a hammer, all of your problems look like nails.
To me, a more fundamental question is why someone would want to save
structs to a database instead of to a flat disk file. I use a database
when I need to find something, not just to store things. For storage,
I just use the much faster naked disk I/O.
C
Sunday, December 11, 2005, 1:14:03 PM, you wrote:
JS> I was describing a free union used to transform big endian to little
JS> endian and vice versa. There is no encoding involved.
JS> My alternatives, BASE64 and ASCII HEX are encodings of the binary integers.
JS> You let the buzzwords drown out the fundamentals.
JS> pps wrote:
John Stanton wrote:
http://www.google.ca/search?q=boost+serialization
I was describing no such thing. An example of what I was describing is
what's serialization?
http://www.google.ca/search?q=serialization
union stored_word
struct
#ifdef BIG_END
...
} a;
#endif
int b;
}
struct stored_doublet {
union stored_word x;
union stored_word y;
}
do you understand that you describe here serialization, and probably one
of the simplest way of doing it, that is not guarantied to work... (as
you say yourself).
I really don't care about this case; making ints byte-endianess
independent doesn't answer question "how do I stode xxx in blobs?"
From an Sqlite perspective the data would be stored as a BLOB since
it is still binary format. It could also be stored as a 64 bit
integer. If it were to be stored as TEXT the transformation could be
more involved and more expensive by using BASE64 or ASCII hex format.
The added cost would be insignificant compared to the prospect of
doing a radix transformation into ASCII decimal and embedding that in
XML then havong to parse it out on every access.
all this is irrelevant, you are talking about encoding. That's obvious,
that xml encoded data is less efficient than ascii or binary encoding.
I just posted xml encoded data as an example.
the same struct ({1,2}) could be serialized by boost::serialization as
text: "1 2" or as binary: (8 bytes: 0x00000001,0x00000002)
most likely, what you are describing will get you the same results as
binary serialization with boost::serialization.
Other than that this library provides you with many things that you were
not even thinkg about at the momnet of writing that code stored_word
etc. (such as serializing data pointed by pointers & restoring pointers,
for example, suppose stored_doublet had an extra member stored_doublet *
next; how well your way handles this case, just think about it... the
best you can do, is to write in big letters that you must be carefull
using this code, etc, etc and then wait for people telling you about
segfaults). What about the case when stored_doublet will be changed? All
the data that was prevoiusly stored in blobs will not be valid anymore?
this case is also handled by boost::serialization
In practical terms it would be best to choose the byte format used by
Intel processors since that would most likely minimize re-ordering.
and, yes, you may save binary data in byte-endianess independent format
or in processor native format also - you may have this choice with
boost::serialization
