#2417: Support for binary type fields (aka: bytea in postgres and VARBINARY in
mysql)
------------------------------------------+---------------------------------
Reporter: [EMAIL PROTECTED] | Owner: nobody
Status: assigned | Milestone:
Component: Database wrapper | Version:
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 1
Needs_better_patch: 0 |
------------------------------------------+---------------------------------
Comment (by mtredinnick):
Thanks for looking at the "make it work across all databases" aspect of
this. That's a necessary part of the process. I had a quick read of the
patch. I like the use of `buffer()`, although just using a bytestring
(Python's `str` type) would have worked to. We might end up using `str`
for simplicity in the end, but that's a very minor thing.
There are a few things that I don't immediately like, however (and I'm
really happy you've done the work here, so take this as a serious design
review as part of getting it into trunk, rather than dissing your effort):
it feels messy to have to test for certain field types in
`Model.__init__`. Part of that would be solved by using (or at least,
permitting) bytestrings instead of buffers. More generally, though, you've
introduced a problem with all other data types. Using `repr(v)` instead of
simply `v` in the `backends/__init__.py` file when you're converting to
unicode means that all the places where smart objects with a
`__unicode__` method are used for database input will no longer work. You
can't do that. I'm also a little surprised that change works, because
calling `unicode()` on something that isn't valid UTF-8 data (which binary
data can easily do) is just going to be broken there. What is you have
data such as `\xff\xff` for example, which isn't valid UTF-8?
Instead, I'd consider creating a special storage type (e.g. `BinaryData`)
analogous to `SafeString`. The database backend wrappers are then taught
to treat such data as binary, rather than converting them to/from unicode.
The conversion between `BinaryData` (or whatever it's called) and `str` or
`buffer` can be done in `db_prep_save()` and `db_prep_load()`, etc. I
haven't done all the research about what is needed to convince each
backend to treat the data as real binary data (rather than converting it
from UTF-8 to Unicode or something) and that was one thing holding up me
doing anything here. From your patch, it looks like the answer is that not
much is required, which is better than I'd hoped, but you have to do
something to not require the change in `backend/__init__.py`.
I'm a little concerned to see `get_manipulator_*` functions being added,
simply because they shouldn't be needed. Manipulators are Old Busted and
newforms-style fields and newforms-admin (which merged probably after you
made this patch, so it's no biggie) are the New Hotness. So nothing
manipulator-related should be needed.
Finally, it will be easier to review the patches if the random blank lines
and print statements around line 157 of `fields/__init.py` weren't there
acting as a distraction.
It's quite possible I'm missing some subtle stuff here and I'll think
about it a bit more to check that, but the above are the main things I'm
concerned about at the moment. Particularly, the leaking of binary data
into `Model.__init__` and the incorrect handling of converting objects to
Unicode strings in `backend/__init__.py`. If anything's not clear, or you
want to bounce ideas around in a better UI than a webform in Trac, feel
free to email me directly.
--
Ticket URL: <http://code.djangoproject.com/ticket/2417#comment:43>
Django Code <http://code.djangoproject.com/>
The web framework for perfectionists with deadlines
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
