improve storage of binary content in the database

[Nils Maier <MaierMan@…>]

r5390/#4087 breaks compatibility with python2.3, as there doesn't seem to be a unicode.decode method.

Patch attached (don't know if this is the best solution though, but works for me at least).
Decoding content via str() should be safe (base64 ;)).

[Nils Maier <MaierMan@…>]

proposed patch, v1

[cboos]

Thanks for the patch.

This code really starts to become scary ;-)
We should really think about a better way to store binary content.

[ecarter]

This ticket should probably not be closed. Especially by anonymous without any explanation.

[anonymous]

Replying to ecarter:

This ticket should probably not be closed. Especially by anonymous without any explanation.

[osimons]

Please don't close as anonymous without explanation.

[eblot]

Edgwall.org really needs a custom workflow to prevent anonymous from randomly changing ticket status...

[cboos]

Now it's a bit late to worry about Python 2.3 compatibility.

However, finding a better and backend neutral way to store binary content is still a goal.

[Carsten Klein <carsten.klein@…>]

I wonder why one would want to improve on storing binary content in the database when there is actually no binary content is being stored in the backend?

I mean, all binary/text attachments to for example wiki pages and tickets are being stored in the filesystem?

And, if that is going to be changed, then I would propose that for both storing of and retrieval of binary content (aka blobs) to and fro the backend, a streaming interface should be used. See for example
​http://www.blobstreaming.org/, see also the referenced links to the right.

Besides that, str is now a replacement for the former unicode api, so there is actually no need to decode or encode it as unicode...

[rblank]

It seems that the SpamFilter plugin stores binary data in the database.

[cboos]

No idea why this was "highest".