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 <[EMAIL PROTECTED]> 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.
--
storm mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/storm
