[storm] Questions about inserts

[David Koblas]

I'll totally agree about the automatic encoding bit.  The design problem 
is that while I _never_ do any collation or sorting of strings in the 
database (eg. no ORDER BY employee_title), it however is handy to do 
from time to time when you're debugging and testing from the sql command 
line.

[don't over generalize the examples, they're for example purposes]

Thus, one is faced with this dilema -- use VARBINARY for all of your 
columns which give you RawStr and make the python code simple:
    find(..., employee_title == 'CEO')
which is a bit more natural than saying employee_title is unicode thus:
    find(..., employee_title == u'CEO')

Now python says:
    >>> print u'CEO' == 'CEO'
    True

While the UnicodeVariable() requires type == unicode, which doesn't 
allow for the natural promotion of str to unicode.

--koblas

Christopher Armstrong wrote:
>> David Koblas <koblas at ...> writes:
>>     
>>> I'm finding it a bit tidious to constantly be casting from str(...) to
>>> unicode(...) to keep the database happy.  Is there really a best
>>> practice for how to have VARCHAR columns that are should be treated as
>>> RawStr() for purposes of development?
>>>       
>
> There is a best practice: It's to never rely on automatic encoding or
> decoding of str and unicode objects. On all I/O boundaries (web input
> / output, email input / output, file I/O, etc), you need to explicitly
> encode and decode with the appropriate encoding (utf-8, ascii, utf-16,
> etc) for the given transport.
>
> If you do end up using automatic encoding and decoding, then your app
> will most likely break some time when a user comes along and decides
> to enter characters that don't fit in ASCII.
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/storm/attachments/20080613/76c6daba/attachment.htm