On Tue, Jun 30, 2009 at 4:26 AM, James Henstridge<[email protected]> wrote: > On Tue, Jun 30, 2009 at 6:17 AM, Jason Baker<[email protected]> 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? -- storm mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
