[storm] Should storm have separate String and Blob datatypes?

[Jason Baker]

On Tue, Jun 30, 2009 at 4:26 AM, James Henstridge<james at jamesh.id.au> wrote:
> On Tue, Jun 30, 2009 at 6:17 AM, Jason Baker<jbaker at zeomega.com> wrote:
>> As of right now, it looks like storm provides one datatype for
>> VARCHAR2 and Binary data.  This makes sense for databases like MySQL
>> and Postgres where you can essentially treat them as the same
>> datatype.  So for instance, this will work under MySQL:
> [snip]
>> Would there be enough of a benefit for everybody to have separate
>> classes for binary and ascii data, or is this something we should just
>> use internally?
>
> The recommended way to use Storm is to use the Unicode property type
> for text columns (char, varchar, text, etc), and the RawStr property
> type for binary data.  Storm will take care of encoding the unicode
> strings in the queries.  The properties are designed so that you can't
> assign a byte string directly  to a Unicode column and can't assign a
> unicode string to a RawStr column.
>
> There are tests for this which use the MySQL BLOB data type.  I'm not
> sure how the rules for blobs compare with those for the BINARY type.
>
> James.
>

Apologies if I'm being dense, but I just want to make sure that I'm
absolutely clear on this.  Oracle relies on having binary data
hexlified.  If it's passed as a bind variable, then this has to be
done on the Python side.  Therefore, if the back end encounters a
RawStr variable, it is safe to assume that it should always be
hexlified before sending it to the database?  Conversely, a person
using Storm should assume that a RawStr *should not* be used to access
textual data?