Well you could do a tuple, but really if the programmer doesn't know what a Bitmask is, they should not be using it. They're by far not a simple technique, and should only be used by those who understand when and why they benefit.
On Dec 6, 3:53 pm, "Craig Kimerer" <[EMAIL PROTECTED]> wrote: > Andrew: Thanks, that looks awesome. > > The whole BitMaskField(choices=LIST) idea scares me. You must then force > extra knowledge on the user that ordering is important. If programmer Y > decides the list of choices looks better in alphabetical order (or decides > to add a choice in the middle of the list), any data that is already in the > table becomes incorrect. > > I guess you have the same problem with people deciding to re-number the > choices, and you can just as easily leave a comment above it that ordering > is important and all new choices should be added to the end. Another option > is to store the choices in something like the django_content_type field and > verify on syncdb (or some other place, not sure where it would go) that any > old field types were not assigned to a new mask. > > Craig > > On Sat, Dec 6, 2008 at 1:12 PM, David Cramer <[EMAIL PROTECTED]> wrote: > > > Awesome to see some people working on this. I had tried pre-queryset > > refactor and It was just not doable witht he fields API. Can't wait to > > see the final result of this :) > > > I'm also agreeing with the API of field = BitMaskField(choices=LIST) > > > On Dec 6, 10:37 am, Carl Meyer <[EMAIL PROTECTED]> wrote: > > > @Andrew: Thanks! That's precisely the missing piece from my code; if > > > I get some time to put it all together, I think it'll be a full > > > solution. My approach uses sets of arbitrary flag values rather than > > > creating constants for flags, and it's implemented as a normal model > > > field, which seems a little cleaner than introducing a new syntax. > > > > @Craig: I never thought of just monkeypatching the necessary > > > dictionaries to add new lookup types. You'd need to do it for all the > > > DB backends, of course. And as with monkeypatching in general, it's > > > not a real sustainable practice to go messing with global reference > > > dicts; if it became common practice to do that for new field types > > > you'd start getting name collisions pretty quickly. I think I'll > > > probably continue to prefer the custom Q object. > > > > Carl --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
