Re: Joining models on M2M field
I think what you're trying to do can be accomplished with the
queryset's .extra() method.
something like
Level.objects.all().extra(select={'unlocked':'count(**matching rows in
the join table**) > 0'})
-Andre
On Dec 30, 7:04 am, Deniz Dogan wrote:
> Hi
>
> I have a user profile which has a many-to-many relationship to a model
> Level. The relationship is called "unlocked" and says which levels a
> specific user has unlocked. Now I wish to retrieve all the levels but
> "joined" with the user's unlocked levels, so that I get a QuerySet
> containing exactly Level.objects.all() but with an extra column called
> "unlocked" which is True if the user has unlocked that level and False
> otherwise.
>
> Is there any way to accomplish this without using explicit SQL?
>
> Any help appreciated,
> Deniz
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Session based messages without touching DB
Sorry, I didn't notice that you said you didn't like the DB hits associated with the session based approach, you can use memcached sessions, or file-backed if avoid the database hits. :P On Dec 5, 12:33 pm, Andre P LeBlanc <[EMAIL PROTECTED]> wrote: > What about the patches on the ticket? The cookie-based approach is > not the right way to do it, as the comments on that page indicate, > these things should be stored server side, especially since it is > being unpickled serverside, it leave a larges security hole. (and the > encryption he later added makes it just silly, just keep it > serverside). > > I really like this idea, the current message system seems pretty > broken to me. I don't see any reason why it should be limited to > authenticated users, when it's the type of thing that can and should > be used for anonymous users as well... I'm thinking "Your comment has > been recieved but must be moderated.." etc. > > The approach used in the patches supplied with the ticket seems sane, > so whether or not its accepted into django it's definitely a good > starting point if you really want that functionality, and I'll > probably use it in my next project. > > Cheers, > Andre > > On Dec 5, 7:51 am, Thomas Guettler <[EMAIL PROTECTED]> wrote: > > > Hi, > > > I use code based on "session based messages" > > from:http://code.djangoproject.com/ticket/4604 > > > What I don't like: There are two database hits, which are not necessary: > > Store message in session-pickle > > and pop message from session-pickle. > > > I found this: > > http://www.djangosnippets.org/snippets/1064/ > > The (flash) message is stored in a cookie. > > > But I think the snippet is not thread safe. Has anyone a working example? > > > Thomas > > > -- > > Thomas Guettler,http://www.thomas-guettler.de/ > > E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Session based messages without touching DB
What about the patches on the ticket? The cookie-based approach is not the right way to do it, as the comments on that page indicate, these things should be stored server side, especially since it is being unpickled serverside, it leave a larges security hole. (and the encryption he later added makes it just silly, just keep it serverside). I really like this idea, the current message system seems pretty broken to me. I don't see any reason why it should be limited to authenticated users, when it's the type of thing that can and should be used for anonymous users as well... I'm thinking "Your comment has been recieved but must be moderated.." etc. The approach used in the patches supplied with the ticket seems sane, so whether or not its accepted into django it's definitely a good starting point if you really want that functionality, and I'll probably use it in my next project. Cheers, Andre On Dec 5, 7:51 am, Thomas Guettler <[EMAIL PROTECTED]> wrote: > Hi, > > I use code based on "session based messages" > from:http://code.djangoproject.com/ticket/4604 > > What I don't like: There are two database hits, which are not necessary: > Store message in session-pickle > and pop message from session-pickle. > > I found this: > http://www.djangosnippets.org/snippets/1064/ > The (flash) message is stored in a cookie. > > But I think the snippet is not thread safe. Has anyone a working example? > > Thomas > > -- > Thomas Guettler,http://www.thomas-guettler.de/ > E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: GeoDjango in Ubuntu 8.10, Segmentation Fault
I had a large table of zip & postal codes which always crashed after about 20 minutes of geocoding them in the ipython shell, i did the same thing several times on the same os, but on a 32-bit machine with no issues. running under mod-python or mod-wsgi on the 64-bit box also seems to randomly throw 500's, but not in any consistent way. On Dec 3, 5:06 am, rcoup <[EMAIL PROTECTED]> wrote: > Hi, > > On Dec 3, 5:21 pm, Andre P LeBlanc <[EMAIL PROTECTED]> wrote: > > > Confirmed also. only happens on my 64-bit machine, and is not related > > to apache at all as I can reproduce it faithfully in ipython. > > I tried pretty hard to replicate it in the console and couldn't - none > of our unit tests crashed it, and neither would anything else i tried. > But the minute it was running under mod-python/mod-wsgi it segfaulted > with the simplest method called on a GEOSGeometry object. > > Rob :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: GeoDjango in Ubuntu 8.10, Segmentation Fault
Confirmed also. only happens on my 64-bit machine, and is not related to apache at all as I can reproduce it faithfully in ipython. On Dec 2, 8:32 pm, GRoby <[EMAIL PROTECTED]> wrote: > I can confirm that all of my seg faults were all on my 64 bit machine > but could not be duplicated when I tried to on my 32 bit test virtual > machines. > > On Dec 2, 7:40 pm, rcoup <[EMAIL PROTECTED]> wrote: > > > Posting to geos-devel, I got this reply from Paul > > Ramsey:http://lists.osgeo.org/pipermail/geos-devel/2008-December/003800.html > > > Leading me to:http://sgillies.net/blog/829/shapely-1-0-8/ > > > "The same problem [segfault] could afflict any python package that > > uses Ctypes on 64-bit systems without explicitly marking argument and > > return types. " > > > Looking back through the modwsgi thread and this one, everyone's on > > 64bit, except the CentOS guy who said it worked ok on 32bit but not on > > 64bit. > > > Maybe thats the problem with the ctypes+geos bindings in GeoDjango? > > I'm running something-pre-1.0, but I can try it on a trunk checkount > > to confirm the same symptoms. > > > Rob :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
