Re: [SQLObject] SQLite fails for binaries

[Ian B. <ia...@co...>]

On Saturday, September 6, 2003, at 07:55 PM, Joshua Rothenberg wrote:
> In an attempt to store binary files in a database, I tried using the
> previously suggested method of base64 encoding them. Whereas this 
> method
> works fine with PostgreSQL, it fails with SQLite. The string retrieved
> from the database is completely garbled from the (encoded) string 
> entered
> into the database. I also tried using hexadecimal encoding with the 
> same
> result. I have no idea what's causing this; is there anything I can do 
> to
> work around this problem? In this instance I wish to avoid using a full
> RDBMS, and I was really hoping to be able to store some images in the
> database (both those for the same reason: at least for now I want all 
> the
> data to reside in one file).  I'm using python 2.3 and had this result
> with both the 0.4 and CVS versions of SQLObject.

 From reading a little documentation, it seems that SQLite cannot have 
binary data because it uses null-terminated strings.  So, encoding is 
the only right way.  But then you tried base64 encoding.  I'm surprised 
that didn't work for you.  Can you give a snippet of the code you were 
using?  It should be quite reliable, so long as you are properly 
encoding and decoding the result, and base64-encoded values should be 
quite safe for insertion.  Is there a possibility the data is being 
corrupted before you put it into the database?  You might test that:

image = (wherever you are getting images from)
soinstance.image = image
assert soinstance.image == image

If that assert works, then the encoding is working.

> Ah, also, (I would respond to the proper message about this, but I 
> wasn't
> subscribed when it was posted), concerning Firebird, there is a pdf at
> http://www.ibphoenix.com/downloads/qsg.pdf that seems to cover all the
> basics of creating databases, etc. (it's linked to via a small image to
> the left of the front page; it's not linked to under documentation or
> anything reasonable like that....)

Thanks, I'll look at that too.  It'll all probably work well once I get 
it set up, but it's been a bit of a pain so far.  People don't give 
proper credit (or blame) for Open Source's general small innovations in 
creating easily administered software.  Anything proprietary (or in 
this case formally proprietary) has lots of difficulties in 
administration.

   Ian