Re: [SQLObject] SQLite fails for binaries

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

On Saturday, September 6, 2003, at 11:36 PM, Joshua Rothenberg wrote:
> On Sat, 06 Sep 2003 22:55:31 -0400
> "Ian Bicking" <ia...@co...> wrote:
>
>> You should add:
>>
>>      def _set_content(self, value):
>>          self._SO_set_content(base64.encodestring(value))
>>      def _get_content(self):
>>          return base64.decodestring(self._SO_get_content())
>>
>> I'm not sure where the problem is, but this will make the whole thing
>> less error-prone.
>
> Well having made that change and tested various things extensively I 
> still have absolutely no clue what's going on, but now when I try to 
> read the img data it tells me "Error: Incorrect padding"... It looks 
> like, among other things, \n's are being turned into \\n's and not 
> being converted back properly (this is from using short strings 
> instead of full images; everything just seems to get garbled with big 
> images).. And it still works properly under PostgreSQL. I have no idea 
> if the problem is with my code, SQLObject's SQLite interface, 
> PySQLite, or SQLite.  Although since it *does* work in other database 
> systems its probably one of the latter three.  Hasn't anyone had this 
> problem before?

Hmm... you're right, SQLite is having some problem with quoting.  It 
seems backslash quoting just doesn't work in SQLite.  Perhaps because ' 
is quoted as '', and all other characters are allowed in the literal 
without quoting.  Except \0, which isn't allowed anywhere.  Hrm.  As a 
stop-gap, I think you can simply remove all the \n's from the 
base64-encoded string, and it's still valid base64 (whitespace is 
ignored).

I was hoping some of this database portability stuff could be avoided 
because database would all act the same (like string literal quoting).  
But maybe that's not the case.  Now... introduce portability in the 
Converters library, or use DBAPI parameters and let the driver do the 
quoting?

   Ian