@ Carl: You can add new syntax for the methods by doing something like this (And maybe there is a better way to do this, still pretty new to Python)
from django.db.backends.mysql.base import DatabaseWrapper DatabaseWrapper.operators['is'] = '& %s' from django.db.models.sql import constants constants.QUERY_TERMS['is'] = None @ Carl & Alex: The above lets you do `flags__is` so you can add them, however, the problem I have is the SQL that is generated is pretty bad for letting you do your own groupings. The SQL where generated looks like: `myapp_person`.`flags` & X Where X is filled in with whatever you are looking for, limited to one & operation. Which is great, except, how do i group these together with multiple flags to check. I could do some horrible things where the sql generated could look like: `myapp_person`.`flags` = `flags` AND (`flags` & X AND `flags` & Y) However the problems arise if I am joining two (or more) tables, how do we know what table the `flags` belongs to without a table name. I can't generate this in the get_db_prep_lookup() because I only know the name of the column, not the name of the table it exists. And this is where I am stuck, I am not exactly sure how to generate the proper SQL for it (the above would look like): (`myapp_person`.`flags` & X AND `myapp_person`.`flags` & Y) Maybe I am going about solving this problem in the wrong way, am I just making this problem overly complicated? Ignoring the fact that it can be solved by the Q, should it be easier to add custom fields? I looked at the contrib.gis app for their custom fields (are there other projects out there that add more complicated fields?), but I didn't see any example where 1 WHERE clause generated more complex SQL then FIELD OP Y or FIELD IN (Y,Z) I will also try to put some work into getting this to work as a Q object on a regular int field. Craig On Fri, Dec 5, 2008 at 8:26 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED] > wrote: > > It should be possible to do this entirely external to Django. The one > thing I would suggest is not to require the user to define the value > for each option, handle that internally. Have some sort of class to > encapsulate the public portion of that. > > Alex > > On Dec 5, 10:53 am, "Mike Axiak" <[EMAIL PROTECTED]> wrote: > > I seem to be missing something. Why is it that you cannot just write a > > BitMaskField yourself outside of Django? > > > > I thought that it might have been that we don't have __any and __all > lookup > > types, but it seems you can override get_db_prep_lookup in a field, so > > that's not an issue. > > > > And if there do seem to be hurdles in creating your own BitMaskField > > (perhaps in syncdb?), then that seems like a limitation in the ORM. > Though, > > everything else I've tried with the ORM recently has shown it to be very > > flexible and I wouldn't expect this to be any different. > > > > -Mike > > > > On Fri, Dec 5, 2008 at 10:11 AM, George Vilches <[EMAIL PROTECTED]> > wrote: > > > > > Unfortunately, Malcolm has shot this down in the past as something > > > that would be included in Django: > > > > >http://groups.google.com/group/django-developers/browse_thread/thread. > .. > > > > > Theoretically, you can do this with a Q object, although I have not > > > tried since Django 1.0 was released. I definitely have a use for this > > > as well, and as can be seen from my original post, every DB engine > > > that Django includes a driver for has support for at very least the & > > > and | operators. > > > > > gav > > > > > On Dec 5, 2008, at 8:20 AM, [EMAIL PROTECTED] wrote: > > > > > > I would use this. The one thing I don't see covered in your example > is > > > > setting flags. I would look at allowing a list or tuple of integers. > > > > Using your example: > > > > > > p = Person(name='John Doe', flags=[PeopleFlags.Male, > > > > PeopleFlags.Employed]) > > > > > > - Justin > > > > > > On Dec 4, 5:16 pm, "Craig Kimerer" <[EMAIL PROTECTED]> wrote: > > > >> Apologies if this has been asked already and I have missed it in > > > >> searching, > > > >> but is there any interest in taking a patch for a BitmaskField? > > > > > >> Given the following (albeit stupid) example to show some usages > > > >> that would > > > >> be nice to have on a bitmask field. I should note in the examples > > > >> below, > > > >> the names I have chosen I am not sold on, but work well enough to > > > >> describe > > > >> what is going on in this example. > > > > > >> class Person(models.Model): > > > >> name = models.TextField() > > > >> flags = models.BitmaskField() > > > > > >> class PeopleFlags(object): > > > >> NoFlag = 0 > > > >> Male = 1 > > > >> Female = 2 > > > >> Student = 4 > > > >> Unemployed = 8 > > > >> Employed = 16 > > > > > >> Example filter API: > > > > > >> Finding all unemployed students: > > > >> Person.objects.filter(flags__all=[PeopleFlags.Unemployed, > > > >> PeopleFlags.Student]) > > > > > >> Finding all females who are students or unemployed > > > >> Person > > > >> .objects > > > >> .filter(flags__is=PeopleFlags.Female).filter(flags__any=[Peop > > > >> leFlags.Student,PeopleFlags.Unemployed]) > > > > > >> Obviously there are some special cases, like you couldn't use the > > > >> same logic > > > >> if someone wanted to find 'All people with NoFlags'. By default 0 > > > >> would > > > >> have to be special cased for '= 0' instead of '& 0'. > > > > > >> I dont have the code currently written, but I am willing to put > > > >> some work > > > >> into it if this is a feature that people (other than me) think > > > >> would be > > > >> useful. > > > > > >> Craig > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
