Re: Using dimension_fields in models.ImageField cause performance penalties
Thank Russ, I have opened a ticket : http://code.djangoproject.com/ticket/15817 Unfortunately, I can't find a easy way to solve the problem because the solution is somewhere in the ImageFileDesciptor.__set__() method which is a dangerous area ! Cordialement, Stanislas. On Apr 12, 2:03 pm, Russell Keith-Magee wrote: > On Mon, Apr 11, 2011 at 8:16 PM, stan wrote: > > The main purpose of the height_field and width_field attributes is to > > give a performance boost in some situations, > > these fields acting as a cache on the dimensions of the image. > ... > > The simple fact of posting an unchanged form of a person cause the > > opening with the PIL of *all* the unmodified images to fill-in the > > dimension_fields of the virtual models in the form validation process. > > > This looks like an unecessary overhead and maybe something more lazy > > could be more appropriate. I am sorry for not coming with a patch - I > > do not get the whole picture of the core - but an expert point of > > views is welcome here :-) > > It sounds to me like you could be right; this strikes me as an > oversight, rather than anything deliberate. It's worth opening a > ticket so that this isn't forgotten. > > Although you're seeing the problem with FormSets, I suspect you'll > find that it exists with normal forms, too -- it just isn't as > pronounced because a formset multiplies the scope of the problem. > > Looking at the code in question, the reference to #11084 is a good > starting point for further analysis. It describes the exact problem > that you're talking about under a slightly different context. I > suspect you'll find that the fix to your problem will be in a similar > mould -- i.e., find a set of conditions that accurately identifies > when a form is being instantiated with existing file data, and ensure > that the dimension update doesn't happen under those conditions. > > Yours, > Russ Magee %-) -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Needed support to delete specialization , while preserving base class instance (multi-table inheritance)
This ticket explains everything: http://code.djangoproject.com/ticket/15579 In short: I issued a ticket on this topic and russellm has closed it with "it's already working" explanation. I checked it again and it looks like this feature is indeed not supported or I'm doing it wrong. Please verify and reopen the ticket if needed. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Needed support to delete specialization , while preserving base class instance (multi-table inheritance)
On Wed, Apr 13, 2011 at 7:45 PM, Piotr Czachur wrote: > This ticket explains everything: http://code.djangoproject.com/ticket/15579 > > In short: > I issued a ticket on this topic and russellm has closed it with "it's > already working" explanation. I checked it again and it looks like > this feature is indeed not supported or I'm doing it wrong. > Please verify and reopen the ticket if needed. On closer inspection, it appears that your original report was correct. I closed it because I thought I had code in production that was using the trick I suggested; however, when I checked, it turns out I'm reparenting a child, not deleting it. My apologies for the confusion. Yours, Russ Magee %-) -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Request for comments: custom admin filters
Hello there, I've just posted a patch with a suggested implementation of custom admin filters: http://code.djangoproject.com/attachment/ticket/5833/5833.custom-filterspecs.3.diff I've written some pretty comprehensive tests and have also had a stab at writing some documentation. You should find all the details there but I thought I'd give a little teaser here first. Here's an example of what you could do with it: The model: class Book(Model): title = models.CharField() pages = models.PositiveIntegerField() The admin: from django.contrib import admin class BookSizeFilter(admin.SimpleListFilter): def get_title(self): return u'size' def get_choices(self, request): return ( (u'small', u'Small'), (u'medium', u'Medium'), (u'large', u'Large'), ) def get_query_set(self, changelist, queryset): size = self.get_value() if size == u'small': return queryset.filter(pages__gte=1, pages__lte=100) if size == u'medium': return queryset.filter(pages__gte=101, pages__lte=200) if size == u'large': return queryset.filter(pages__gte=201) return queryset class BookAdmin(admin.ModelAdmin): list_filter = [BookSizeFilter,] Custom filters is a feature that has been requested by many people and for a long time. If you're one of those eager people, it would be awesome if you could take a look at the patch and, if you like the proposed API, try it in your own real projects to see if all the edge cases are covered. I'm also really keen to hear your thoughts on the various sub-features that ship with that patch, on the suggested API, and on the various implementation details. The patch is pretty hefty so I'd really like to take this to a close ASAP before it grows stale and becomes harder to maintain. Many thanks! Julien :-) -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Request for comments: custom admin filters
Hi Julien -- Thanks for your work on this! I'm working my way through the patch, and it's looking good. I'm pretty happy with the internals, though I do have some questions about the public API: * I'm rather unhappy with the `SimpleListFilter`/`FieldListFilter` breakdown, and especially the way `FieldListFilter` is documented. This isn't friendly: Note that this method is far more complex than simply using a field name or a ``SimpleListFilter`` class, as there currently is no simple way available to manipulate a ``FieldListFilter``. You may, however, find some useful examples with the built-in filters defined in :mod:`django.contrib.admin.filterspecs`. Ugh. It seems to me that `FieldListFilter` is something of an internal detail required to maintain the existence of a bunch of pre-refactor stuff, right? If so, I think I'd like to see `SimpleListFilter` renamed to something more obvious (maybe call it `ListFilter` and call the parent class `BaseListFilter` or collapse it into a single class). Then the docs can explain that a list filter could be a `FieldListFilter` but that that API is considered internal and prone to change/refactoring. Make sense? * There's a weird discrepancy (to me) between the signatures of `get_choices(self, request)` and `get_query_set(self, changelist, queryset)`. I'd expect to have the `request` available to both methods, I think, and I don't really know what `changelist` is doing there or what I'd use it for. Can you talk a bit about why those signatures work that way? * `def get_title(self): return "size"` seems like overkill -- why not just `title="size"`? Thanks again! Jacob -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Error importing template source loader when upgrading from r15883 to r16025
Hello,
I have a small web site that was running happily with django r15883
that I updated March 21st.
Yesterday I upgraded to the latest version (r16025) and then I'm
getting an error that 505s my site:
Error importing template source loader
django.template.loaders.filesystem.load_template_source: "'module'
object has no attribute 'load_template_source'"
at /usr/lib/python2.6/dist-packages/django/template/loader.py in
find_template_loader, line 101
I couldn't find anything related to this in my web searches including
http://code.djangoproject.com.
I'm running Apache 2.2 on Ubuntu 10.10, everything pretty updated.
I just rolled back to the previous version, but just leaving this
here, I'm not even sure this is the right place.
I checked the changes done between the two versions with svn log -r
{2011-03-20}:{2011-04-12} and these two commits are what they look as
possible candidates for this issue:
Advanced deprecations in django.template.
r15986 | russellm | 2011-04-02 04:41:26 -0400 (Sat, 02 Apr 2011) | 1
line
Removed support code for deprecated module-based template loaders from
debug view postmortem.
r16004 | ramiro | 2011-04-02 15:03:11 -0400 (Sat, 02 Apr 2011) | 1
line
Thanks.
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Error importing template source loader when upgrading from r15883 to r16025
On 13 April 2011 18:37, lazyant wrote: > Hello, > > I have a small web site that was running happily with django r15883 > that I updated March 21st. > > Yesterday I upgraded to the latest version (r16025) and then I'm > getting an error that 505s my site: > > Error importing template source loader > django.template.loaders.filesystem.load_template_source: "'module' > object has no attribute 'load_template_source'" Well, function-based template loaders have been deprecated in Django 1.2; With recent release of Django 1.3, trunk is now 1.4 and they have been removed as documented here: http://docs.djangoproject.com/en/dev/releases/1.2/#class-based-template-loaders http://docs.djangoproject.com/en/dev/releases/1.2/#function-based-template-loaders You also should be getting DeprecationWarnings about this. If you're on python >= 2.7, try running "python -W manage.py runserver". -- Łukasz Rekucki -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Request for comments: custom admin filters
Hi Julien, Thanks for working on this! Will your patch simplify creating filters not based on choices? E.g. min/max filters where exact minimun and maximum values can be entered (using form with method=GET and input fields for values)? I want a pony ;) It would also be good to make FilterSpec.output using template, not the hardcoded python. On 13 апр, 23:11, Jacob Kaplan-Moss wrote: > Hi Julien -- > > Thanks for your work on this! I'm working my way through the patch, > and it's looking good. I'm pretty happy with the internals, though I > do have some questions about the public API: > > * I'm rather unhappy with the `SimpleListFilter`/`FieldListFilter` > breakdown, and especially the way `FieldListFilter` is documented. > This isn't friendly: > > Note that this method is far more complex than simply using a field > name or a ``SimpleListFilter`` class, as there currently is no simple > way available to manipulate a ``FieldListFilter``. You may, however, > find some useful examples with the built-in filters defined in > :mod:`django.contrib.admin.filterspecs`. > > Ugh. > > It seems to me that `FieldListFilter` is something of an internal > detail required to maintain the existence of a bunch of pre-refactor > stuff, right? If so, I think I'd like to see `SimpleListFilter` > renamed to something more obvious (maybe call it `ListFilter` and call > the parent class `BaseListFilter` or collapse it into a single class). > Then the docs can explain that a list filter could be a > `FieldListFilter` but that that API is considered internal and prone > to change/refactoring. Make sense? > > * There's a weird discrepancy (to me) between the signatures of > `get_choices(self, request)` and `get_query_set(self, changelist, > queryset)`. I'd expect to have the `request` available to both > methods, I think, and I don't really know what `changelist` is doing > there or what I'd use it for. Can you talk a bit about why those > signatures work that way? > > * `def get_title(self): return "size"` seems like overkill -- why not > just `title="size"`? > > Thanks again! > > Jacob -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Error importing template source loader when upgrading from r15883 to r16025
On Wed, Apr 13, 2011 at 1:37 PM, lazyant wrote:
> Hello,
>
> I have a small web site that was running happily with django r15883
> that I updated March 21st.
>
> Yesterday I upgraded to the latest version (r16025) and then I'm
> getting an error that 505s my site:
>
> Error importing template source loader
> django.template.loaders.filesystem.load_template_source: "'module'
> object has no attribute 'load_template_source'"
>
> at /usr/lib/python2.6/dist-packages/django/template/loader.py in
> find_template_loader, line 101
>
> I couldn't find anything related to this in my web searches including
> http://code.djangoproject.com.
>
> I'm running Apache 2.2 on Ubuntu 10.10, everything pretty updated.
>
> I just rolled back to the previous version, but just leaving this
> here, I'm not even sure this is the right place.
>
> I checked the changes done between the two versions with svn log -r
> {2011-03-20}:{2011-04-12} and these two commits are what they look as
> possible candidates for this issue:
>
> Advanced deprecations in django.template.
>
> r15986 | russellm | 2011-04-02 04:41:26 -0400 (Sat, 02 Apr 2011) | 1
> line
>
> Removed support code for deprecated module-based template loaders from
> debug view postmortem.
>
> r16004 | ramiro | 2011-04-02 15:03:11 -0400 (Sat, 02 Apr 2011) | 1
> line
Function-based template loader were deprecated in Django 1.2
and will be removed in 1.4. They were replaced with class
a based loader API
http://code.djangoproject.com/changeset/11862
You seem to be running your site against trunk, and we've
started to delete the code scheduled to be removed in 1.4 a
few days after the release of 1.3, the two commits you isolated
are part of that.
It is not clear to me if you are using a custom template loader
(in such case you need to adapt it to conform to the new API),
or if you have some weird Django setup problem with both
old and new code. Maybe you can share tat with us once
you discover what's happening?
Regarding the documentation, unfortunately the documentation
changes introduced together with the code changes didn't include
proper markup to signal the specific modifications perfoemed
nor a related section in the respective release notes.
We tried to correct these omissions somewhat late during the 1.3
development cycle. The changeset is r15309
http://code.djangoproject.com/changeset/15309
and it adds the text sections Lucasz pointed you at.
It was also backported to the 1.2.X branch and th 1.2.5
release included these new doc blurbs.
Regards,
--
Ramiro Morales
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: RFC #2705 (Support for SELECT FOR UPDATE)
Hi, Sorry to bump this one again. Now 1.3's out the door, I'd like this to be looked at again, if possible. http://code.djangoproject.com/ticket/2705 I'll re-apply Ramiro's patch locally and make sure everything still checks out for me, and report back. The latest version of the patch still applied cleanly for me and passed tests when I tried it again late last week (r15043). I've cleaned up the docs as per Jacob and Carl's points in their last review (thanks for those!). As mentioned in the ticket, I've also run the full suite against PostgreSQL, MySQL, SQLite and Oracle; there are no more breakages after the patch was applied than before it was applied. However, it's worth mentioning that the Oracle tests seemed to be mostly broken in the first place, with dozens of errors. Aside from the docs issues that I've fixed, Jacob said he thought this was RFC - it'd be great to see that happen. As ever, let me know on the ticket if there's anything else that needs to be done. Thanks, Dan -- Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Error importing template source loader when upgrading from r15883 to r16025
Hi, Thanks for the quick answers. I fixed the problem by changing in settings.py TEMPLATE_LOADERS: 55 55 TEMPLATE_LOADERS = ( 56 - 'django.template.loaders.filesystem.load_template_source', 57 - 'django.template.loaders.app_directories.load_template_source', 56 + 'django.template.loaders.filesystem.Loader', 57 + 'django.template.loaders.app_directories.Loader', I also added for MIDDLEWARE_CLASSES django.middleware.csrf.CsrfViewMiddleware, django.contrib.messages.middleware.MessageMiddleware I'm not running any custom template loader. I may be mixing new and old code, or rather all code would be 'old', as in working as original for many months. I did have the deprecation warnings in my apache error log, although they were buried by these other messages: http://code.google.com/p/modwsgi/issues/detail?id=197 , and even if it's said that the issue was fixed in r1588 I still have them (perhaps my mod_wsgi from ubuntu 10.10 repo is not new enough), funny this was the reason for the upgrade. The link http://docs.djangoproject.com/en/dev/releases/1.2/#class-based-template-loaders says "so there is no immediate need to modify your TEMPLATE_LOADERS setting in existing projects, things will keep working if you leave it untouched up to and including the Django 1.3 release." so I guess I caught the removal of deprecated stuff between 1.3 and 1.4. OK. TL;DR: look at your error messages, update settings.py if using devel branch. "If you choose to follow the development version, keep in mind that there will occasionally be backwards-incompatible changes. If you're just looking for a stable deployment target and don't mind waiting for the next release, you'll want to stick with the latest official release" Thanks -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: RFC #2705 (Support for SELECT FOR UPDATE)
On Wed, Apr 13, 2011 at 2:08 PM, Dan Fairs wrote: > However, > it's worth mentioning that the Oracle tests seemed to be mostly broken in > the first place, with dozens of errors. Thanks for following up on those. I reviewed the Oracle tests shortly before the 1.3 release and fixed all the real failures in the backend. The remaining failures as of then were due to the backend not interacting well with the test suite as documented in ticket #15573, plus a DB cache issue in #15580. Thanks, Ian -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Request for comments: custom admin filters
Hi Mikhail, On Apr 14, 4:56 am, Mikhail Korobov wrote: > Will your patch simplify creating filters not based on choices? E.g. > min/max filters where exact minimun and maximum values can be entered > (using form with method=GET and input fields for values)? I want a > pony ;) No, this patch does not allow this. This would be a new separate feature. Feel free to open a ticket ;) > It would also be good to make FilterSpec.output using template, not > the hardcoded python. I totally agree that using a template would be better, but I'd like to keep this patch focused on what has been requested in #5833. Again, feel free to open a specific ticket for that ;) Julien -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: combining querysets with isnull
On Thursday, October 14, 2010 7:03:35 PM UTC-4, Johannes Dollinger wrote:
>
>
> Am 14.10.2010 um 23:07 schrieb Dan Watson:
>
> > There seems to be some inconsistent behavior when combining querysets
> > that use isnull on a ForeignKey. I'm not sure how to explain it well
> > in plain english, so here's a boiled-down example:
> >
> > # Models
> >
> > class Item (models.Model):
> >title = models.CharField( max_length=100 )
> >
> > class PropertyValue (models.Model):
> >label = models.CharField( max_length=100 )
> >
> > class Property (models.Model):
> >item = models.ForeignKey( Item, related_name='props' )
> >key = models.CharField( max_length=100 )
> >value = models.ForeignKey( PropertyValue, null=True )
> >
> > # Example
> >
> > item = Item.objects.create(title='Some Item')
> > pv = PropertyValue.objects.create(label='Some Value')
> > item.props.create(key='a', value=pv)
> > item.props.create(key='b')
> > q1 = Q(props__key='a', props__value=pv)
> > q2 = Q(props__key='b', props__value__isnull=True)
> > qs1 = Item.objects.filter(q1) & Item.objects.filter(q2)
> > qs2 = Item.objects.filter(q2) & Item.objects.filter(q1)
> >
> > I would have expected qs1 and qs2 to yield the same result, but they
> > do not. They should both return the single item, but qs1 returns
> > nothing. The SQL for qs1 looks like:
> >
> > SELECT "app_item"."id", "app_item"."title" FROM "app_item"
> > INNER JOIN "app_property" ON ("app_item"."id" =
> > "app_property"."item_id")
> > LEFT OUTER JOIN "app_property" T4 ON ("app_item"."id" = T4."item_id")
> > LEFT OUTER JOIN "app_propertyvalue" T5 ON ("app_property"."value_id" =
> > T5."id")
> > WHERE (("app_property"."value_id" = 1 AND "app_property"."key" =
> > 'a' ) AND (T5."id" IS NULL AND T4."key" = 'b' ))
> >
> > The first app_property join corresponds to q1, and the second
> > corresponds to q2. However, the app_propertyvalue join (corresponding
> > to the isnull from q2) refers to app_property.value_id (i.e. q1)
> > instead of T4.value_id (i.e. q2). I think fixing #10790 would fix
> > this, since removing the join to app_propertyvalue and simply checking
> > "T4.value_id IS NULL" works as expected, but I'm not sure if this is a
> > separate problem worthy of another ticket or not. Also (less
> > importantly), since both criteria (q1 and q2) are checking
> > props__key='something', I would imagine both joins could be INNER
> > JOINs, but the isnull seems to promote the second to a LEFT OUTER
> > JOIN.
> >
> > I guess I was just wondering if I should open a separate ticket for
> > this, or is this simply a symptom of #10790? Or am I missing
> > something?
>
> Your problem looks like #11052 [1].
>
> [1] http://code.djangoproject.com/ticket/11052
>
> __
> Johannes
>
Looking at this further, I think the problem is slightly different. #11052
[1] describes a situation where joins are not promoted where they should be.
The attached patch also did not produce correct results for my test case. I
think #10790 [2] is more closely related, but still isn't exactly the issue
(and again, the attached patch does not fix my test case). The issue I'm
seeing is that, when combining queries, the join conditions do not reference
aliases from the "correct" side in all cases. In my example above, the join
to T5 should have referenced T4 since they both came from the right side of
the combination. However, the combine method does not check to see if the
left side of the join condition (for tables on the right) has already been
re-aliased. I've opened ticket #15823 [3] with a patch that passes all
tests, and a new regression test. As these internals get pretty hairy, I'd
love if someone could take a look and make sure this is the correct
approach.
Dan
[1] http://code.djangoproject.com/ticket/11052
[2] http://code.djangoproject.com/ticket/10790
[3] http://code.djangoproject.com/ticket/15823
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Request for comments: custom admin filters
On Apr 14, 3:11 am, Jacob Kaplan-Moss wrote: > Hi Julien -- > > Thanks for your work on this! I'm working my way through the patch, > and it's looking good. I'm pretty happy with the internals, though I > do have some questions about the public API: > > * I'm rather unhappy with the `SimpleListFilter`/`FieldListFilter` > breakdown, and especially the way `FieldListFilter` is documented. > This isn't friendly: > > Note that this method is far more complex than simply using a field > name or a ``SimpleListFilter`` class, as there currently is no simple > way available to manipulate a ``FieldListFilter``. You may, however, > find some useful examples with the built-in filters defined in > :mod:`django.contrib.admin.filterspecs`. > > Ugh. > > It seems to me that `FieldListFilter` is something of an internal > detail required to maintain the existence of a bunch of pre-refactor > stuff, right? If so, I think I'd like to see `SimpleListFilter` > renamed to something more obvious (maybe call it `ListFilter` and call > the parent class `BaseListFilter` or collapse it into a single class). > Then the docs can explain that a list filter could be a > `FieldListFilter` but that that API is considered internal and prone > to change/refactoring. Make sense? > > * There's a weird discrepancy (to me) between the signatures of > `get_choices(self, request)` and `get_query_set(self, changelist, > queryset)`. I'd expect to have the `request` available to both > methods, I think, and I don't really know what `changelist` is doing > there or what I'd use it for. Can you talk a bit about why those > signatures work that way? > > * `def get_title(self): return "size"` seems like overkill -- why not > just `title="size"`? > > Thanks again! > > Jacob Hi Jacob, Thanks a lot for your feedback. I agree with all your points and have made the corresponding amendments in a new patch: http://code.djangoproject.com/attachment/ticket/5833/5833.custom-filterspecs.4.diff Let me know if you've got any further feedback on this. Cheers! Julien -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Tying log messages from a single request together?
Hi, Is there an idiomatic way to tie messages from a single request together with 1.3's new logging features? From the documentation it doesn't look like there is. Something like what drlog does ( http://fairviewcomputing.com/blog/2008/03/05/django-request-logging/). It seems like a standard thing to do in a web application so that's why I'm asking. I feel like I'm missing something. The implementation would probably be some middleware that creates a request id and sticks that and the request in thread local storage. Then a logging.Filter that attaches those to the log record. Thanks, Shawn -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Request for comments: custom admin filters
On Apr 14, 8:46 am, Julien Phalip wrote: > Thanks a lot for your feedback. I agree with all your points and have > made the corresponding amendments in a new > patch:http://code.djangoproject.com/attachment/ticket/5833/5833.custom-filt... Sorry, just in case you've already started reviewing the patch (but no rush!), I've just realised I had missed one small thing in it, which is now fixed: the get_query_set() method now receives the request as parameter too. Everything is now ready for review in the latest patch: http://code.djangoproject.com/attachment/ticket/5833/5833.custom-filterspecs.5.diff Thank you! Julien -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
