Re: Cleaning up memcached connections
On 30-Oct-07, at 10:55 PM, webjunkie wrote: >> Err, what was the old version, and what's the new version? >> >> "Upgrade" is kind of vague. :-/ > > Upgraded from 3.2.10 to 3.3.1 ;) which is 8 months old ;-) -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/web/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Bitwise operations in QuerySets?
On Tue, 2007-10-30 at 17:03 -0400, George Vilches wrote: > What I want to do: Assume I have an integer column in a table that > contains a value that I want perform a bit operation on. I would like > to able to make a QuerySet that generates a query similar to this: > "SELECT * FROM table WHERE column & 4;". (example is MySQL-friendly). > > I've looked around both in the current DB layer and in > Queryset-refactor, but it's possible I've missed something. If this > already exists, then give me the shaming I deserve. Otherwise... > > > Would anyone object to it being just another __ operation? For > instance, Poll.objects.filter(column__bitand=4). Is there a preference > whether this should be __and or __bitand? Yeah, I'd object. I don't see it as common enough to warrant inclusion. You can achieve the same functionality either with extra(where=...) or a custom Q-like object, so I'm inclined to leave it out of core. By the way, in the queryset-refactor Q-like objects will have access to the full query class, which includes the model, so you'll be able to write something like Bit(foo__and=4) and when it comes time to produce the SQL, your Bit class will be able to work out the right column name for model field "foo". Regards, Malcolm -- Quantum mechanics: the dreams stuff is made of. 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 -~--~~~~--~~--~--~---
Re: multi-db branch
On Oct 29, 3:31 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > You probably want to start by reading messages here: > > http://groups.google.com/group/django-developers/search?q=multi-db... So it sounds as if the branch is dead, and there are patches being attached to #4747? I'd be willing to pitch in some time to get the multi-db code up to snuff, if there is a clear road ahead for what needs to be done. If there isn't I can live with that too :-) //Ed --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Cleaning up memcached connections
On Oct 31, 4:25 am, webjunkie <[EMAIL PROTECTED]> wrote: > On Oct 30, 4:53 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote: > > > > > Err, what was the old version, and what's the new version? > > > "Upgrade" is kind of vague. :-/ > > Upgraded from 3.2.10 to 3.3.1 ;) Except that I still can't see why upgrading from mod_python 3.2.10 to 3.3.1 would make a difference. The only remote possibility would be because the older module importer in mod_python 3.2.10 was causing a problem because of the way that it overlays a reloaded module on top of an old one. Issue with this being the reason is that it shouldn't be applying reloading to code modules in Django and can't therefore see how it would trigger the problem with the old module loader. So, I am still mystified. Graham --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Bitwise operations in QuerySets?
What I want to do: Assume I have an integer column in a table that contains a value that I want perform a bit operation on. I would like to able to make a QuerySet that generates a query similar to this: "SELECT * FROM table WHERE column & 4;". (example is MySQL-friendly). I've looked around both in the current DB layer and in Queryset-refactor, but it's possible I've missed something. If this already exists, then give me the shaming I deserve. Otherwise... Would anyone object to it being just another __ operation? For instance, Poll.objects.filter(column__bitand=4). Is there a preference whether this should be __and or __bitand? I don't know if this makes sense for | (bitwise-OR), since you would need to be able to specify something more like this: "SELECT * FROM table WHERE column | 4 > 12;". "SELECT * FROM table WHERE column | 4 = 12;". Which may not be appropriate for a simple queryset operator in Django. However, it would be cool if there was some way to support that with a more complicated Q() or the like, but I could see it being out of scope of Django, so ignore this part if so. Bitwise-XOR, I don't know, some specific usages maybe. I've already verified that all the DBs Django supports have some mechanism for doing the basic bitwise operations.[1][2][3][4][5] I don't mind doing this only against the qs-rf branch, and I can build the tests and patch, but wanted to get the community opinion first. I'm +1 on & (bitwise-AND), -0 on | (bitwise-OR, pending someone giving a neat example), and +0 on bitwise-XOR/the rest, but would like to find some way to be +1 on all of them. Thoughts? Thanks, George [1] SQLite: http://www.sqlite.org/changes.html [2] MySQL: http://dev.mysql.com/doc/refman/5.0/en/bit-functions.html [3] MSSQL: http://www.functionx.com/sqlserver/Lesson03.htm [4] PostgreSQL: http://www.postgresql.org/docs/8.1/interactive/functions-math.html [5] Oracle: http://www.jlcomp.demon.co.uk/faq/bitwise.html --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: setup_environ question
On Oct 27, 2007 3:12 PM, Gary Wilson <[EMAIL PROTECTED]> wrote: > > Is there a reason why setup_environ adds the parent directory of the project > directory to the path, imports the project module, and then removes the parent > directory from the path? The imported project module is also not used > afterwards. To put it into sys.modules? (Not very useful, but it's the only side-effect that occurs to me) -- Leo Soto M. http://blog.leosoto.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Choice lookups
> On 10/30/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> > James, I think you've managed to hit (what I'd consider) the perfect
> > stride there. You have to import Entry anyway, so by making your
> > constants class attributes, you avoid the extra import requirement.
>
> It's not quite an enum, but it's close enough for my taste.
It works great for me too.
Though on further reflection, I think Jeremy's asking for something
> that's legitimately useful: it'd be nice to have some way to accept
> the human-readable value (say, in a URL) and use it to do the lookup
> with that.
Are there i18n issues that pop up here? what is the reverse of {0:_("my
value")}?
Rob :)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Choice lookups
On 10/30/07, James Bennett <[EMAIL PROTECTED]> wrote: > Though on further reflection, I think Jeremy's asking for something > that's legitimately useful: it'd be nice to have some way to accept > the human-readable value (say, in a URL) and use it to do the lookup > with that. Hrm, I hadn't really considered URLs, to be honest. I actually have a situation that could indeed benefit from that. /contact/ /contact/president/ /contact/treasurer/ etc... -Gul --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Choice lookups
On 10/30/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > James, I think you've managed to hit (what I'd consider) the perfect > stride there. You have to import Entry anyway, so by making your > constants class attributes, you avoid the extra import requirement. It's not quite an enum, but it's close enough for my taste. Though on further reflection, I think Jeremy's asking for something that's legitimately useful: it'd be nice to have some way to accept the human-readable value (say, in a URL) and use it to do the lookup with that. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Choice lookups
James, I think you've managed to hit (what I'd consider) the perfect stride there. You have to import Entry anyway, so by making your constants class attributes, you avoid the extra import requirement. I hereby retract my +0 in favor of a -0. Either way, I'm still stuck at "meh." -Gul --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Choice lookups
Wow, that's an interesting idea. I don't think I'd use it very often, but I definitely like the idea. It would add a little bit of overhead beyond the existing, but that's only when people actually use it, and I expect that won't be terribly often. This seems like the kind of thing that would be most useful in a urlconf, specifying base querysets for use with generic views. These would only get called once when the module is loaded, so the impact would be minimal. Views would likely be doing lookups based on user input, rather than programmer input, so those probably wouldn't use it much. The only other performance hit I can think of would be in models that use it to reference subsets of related models. And in those cases, if it's really a problem, it's still easy and readable to just expect programmers to scroll up to the CHOICES assignment and see what the number refers to. Of course, I tend to assign those numbers to constants, which I then reference, but you're right that it still requires an input in order to use that outside of the file where it's defined. All in all, I kinda like it, but I doubt I'll use it. +0 I suppose. One thing I'd add is a check that the value is in fact present in the display list before running the query. For instance, if 'parrot' wasn't actually a valid option, the QuerySet could figure that out and return an EmptyQuerySet instead, without ever touching the database (since it wouldn't even know what to look for anyway). It's either that or throw an error. I'd hate to see that behavior undefined. -Gul --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Choice lookups
On 10/30/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > It's always bugged me a little that choice lookups are based on the raw value. > > Example for discussion: > CHOICES = ( >(1, 'parrot'), >(2, 'argument'), > ) > > class Profile(models.Model): > user = FK(User) > favorite_skit = IntegerField(choices=CHOICES) > > > In staticly-typed languages, and paraphrasing a bit, lookups like this > are based on enums. Hm. Actually, what I've typically done is something like this (ripped from my blog code): class Entry(models.Model): LIVE_STATUS = 1 DRAFT_STATUS = 2 STATUS_CHOICES = ( (LIVE_STATUS, 'Live'), (DRAFT_STATUS, 'Draft') ) status = models.IntegerField(choices=STATUS_CHOICES) # ...etc. Which then leads fairly naturally into lookups like Entry.objects.filter(status__exact=Entry.LIVE_STATUS) It's a bit more typing, but I like the way it encapsulates the choices into the model class, and it leads to much more readable lookups (without a need for magic numbers). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Choice lookups
It's always bugged me a little that choice lookups are based on the raw value. Example for discussion: CHOICES = ( (1, 'parrot'), (2, 'argument'), ) class Profile(models.Model): user = FK(User) favorite_skit = IntegerField(choices=CHOICES) In staticly-typed languages, and paraphrasing a bit, lookups like this are based on enums. Querying for parrot lovers: Profile.objects.filter(favorite_skit=1) which is kind of unreadable. It'd be nice if we could do this: Profile.objects.filter(favorite_skit__display='parrot') That is, introduce a new __display lookup type which accepts a string and tries to get the raw value based on the choices kwarg on that field. (A little utility could be added for choice reversal: REV_CHOICES = dict((v,k) for (k,v) in CHOICES) Profile.objects.filter(favorite_skit=REV_CHOICES['parrot']) but that's a sideline; you still have to do the import and it's a bit verbose, especially if you consider likely namespace collisions. ) The only complaint I can see for this is that some people may be using different raw values to map to the same display value, but the new __display lookup type would just be another way; querying with raw values would still work. Thoughts? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Cleaning up memcached connections
On Oct 30, 4:53 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote: > > Err, what was the old version, and what's the new version? > > "Upgrade" is kind of vague. :-/ Upgraded from 3.2.10 to 3.3.1 ;) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Cleaning up memcached connections
On 10/30/07, webjunkie <[EMAIL PROTECTED]> wrote: > > I had the same problem today. I can confirm that it's fixed with a > newer mod_python. > http://groups.google.com/group/django-users/browse_frm/thread/5718bb2a94ebec2 > Err, what was the old version, and what's the new version? "Upgrade" is kind of vague. :-/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Cleaning up memcached connections
I had the same problem today. I can confirm that it's fixed with a newer mod_python. http://groups.google.com/group/django-users/browse_frm/thread/5718bb2a94ebec2 On Oct 26, 6:59 am, Chris Henderson wrote: > I ran into this when I was running benchmarks with ab2 on an Ubuntu > Dapper box. I ended up just using the patch that you provided to fix > the problem, but after I installed gutsy recently, I noticed that the > problem was no longer occurring on a straight svn Django checkout > (without the fix). It seems that whatever the problem was (at least for > me), it was fixed in mod_python 3.3.1. To make sure this was really > what fixed it, I manually compiled 3.3.1 on a dapper machine that > previously had the issue, and it went away. Maybe someone who knows > more than me about mod_python would know why.. > > chris. > > > > Jacob Kaplan-Moss wrote: > > Hi all -- > > > We've noticed that in a few cases Django under mod_python can leave > > dangling connections to memcached open. We've had trouble tracking > > down the circumstances under which this happens, but when it does it > > can lead to memcached servers hitting their connection limits, which > > means caching stops. Nasty. > > > I've fixed the problem, and the patch is at > >http://code.djangoproject.com/attachment/ticket/5133/memcached-cleanu..., > > but I'm not sure about the ramifications of the fix. Thoughts before I > > check this in? > > > Jacob- Hide quoted text - > > - Show quoted text - --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: shortcut to display one field from newforms
The as_* methods are helpers to display the form fields quickly. As
mentioned above you can accomplish exactly what you are describing.
Just create a templatetag to make it more DRY.
On Oct 30, 2:52 am, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> > On the other hand, it's kind of an edge case, since if you're using the
> > same set of tags for every field, it quite limits the amount of
> > customized layout you can do :)
>
> I don't think so - most of the people control the layout via css
>
> I think using {{ form.foo.as_p }} is a great idea.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[no subject]
-- Warner Leijenaar --- [EMAIL PROTECTED] [EMAIL PROTECTED] [w] http://renraw.nl/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Reverse Engineer + Database + Models
Hello, I am a new to Django.. i just wanted to know if i could reverse engineer an existing database tables to Model.py files is there any tool to do this? Regards, Arun --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: shortcut to display one field from newforms
> On the other hand, it's kind of an edge case, since if you're using the
> same set of tags for every field, it quite limits the amount of
> customized layout you can do :)
I don't think so - most of the people control the layout via css
I think using {{ form.foo.as_p }} is a great idea.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Reverse Engineer + Database + Models
On 30-Oct-07, at 12:07 PM, aruns wrote: > I am a new to Django.. dont crosspost to both users and developers - stick to users unless you are going to join in developing django itself -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/web/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: FileField question
On 29/10/2007, Justin Driscoll <[EMAIL PROTECTED]> wrote: > > To me having the two mutually-exclusive arguments sounds too much like > trying to fake static typing in a dynamic language. I don't see the > advantage of separate names for basically the same information provided in > different ways. If it walks like a duck... > > if callable(upload_to): > self.upload_to, filename = os.path.split(upload_to()) > else: > self.upload_to = upload_to After considering it again I think this would be the simple and compatible way to go. The only caveat would be to clearly specify in the docs that if you use a callable it must return a full path including filename. Rob :) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
