On Tue, 2007-08-14 at 16:29 -0700, Simon Greenhill wrote: > The last time we discussed this [1] I think everyone sort of concluded > that a binary field was a sensible idea as long as it's PRIMARILY for > storing small chunks of binary info, and not an easy-I-want-to-store- > binaries-in-my-database type of thing. > > >From memory, most of the issues in that discussion have been rounded > up and sort-of dealt with in #2417 [2]. Someone (a BDFL-type) needs to > look over that and work out what we want in Django, and someone else > needs to champion the issue. 2417 certainly needs to be updated to > include things like Oracle, and needs tests.
I suspect it might also need a new design post-Unicode merge. I haven't read it too carefulyl lately, but I wouldn't be surprised if the data passed to the database would current pass through some attempt to convert it to and from Unicode as it crosses the Django/database barrier. That's not desirable for binary data. One solution is to wrap the binary data in a class, so it has a type that is not derived from basestring and thus, to_str() works sensibly on it at the database layer. Or perhaps the database layers (django/db/backends/*/base.py) would need special handling for this class so that it doesn't try to quote it. The trip from database to Django probably isn't a problem, providing we remember to ensure that BLOB fields aren't auto-decoded (vague memory that MySQL installs an encoding-related converter on BLOB types, at least in mysql_old with older MySQLdb instances). In any case, testing against current trunk with binary data that is definitely not valid UTF-8 is necessary. > > Aside: can we make it easy for people to make their own field types? > There's a lot of tickets out there with all sorts of weird and > wonderful field things that we probably don't need to add to Django, > but if people know how to customise them, then they can do what they > want. Yeah, work in progress on my side. It can all be done already once we check in a patch to allow custom SQL in management.py. The only real extensions we are making is to make it easier in the common case (so you don't have to write your own __set__, __get__ and contribute_to_class methods for the simple case) and documentation. I'll finish it soon. Regards, Malcolm -- Experience is something you don't get until just after you need it. http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
