[Changeset] r11779 - in django/branches/soc2009/multidb: . django/db

[noreply]

Author: Alex
Date: 2009-11-26 01:26:05 -0600 (Thu, 26 Nov 2009)
New Revision: 11779

Modified:
   django/branches/soc2009/multidb/TODO
   django/branches/soc2009/multidb/django/db/__init__.py
   django/branches/soc2009/multidb/django/db/utils.py
Log:
[soc2009/multidb] Fix a number of tests when run under an old style settings 
(i.e. using the DATABASE_* settings).

Modified: django/branches/soc2009/multidb/TODO
===
--- django/branches/soc2009/multidb/TODO2009-11-23 21:40:09 UTC (rev 
11778)
+++ django/branches/soc2009/multidb/TODO2009-11-26 07:26:05 UTC (rev 
11779)
@@ -11,6 +11,15 @@
 * validate() on a field
 * name/purpose clash with Honza?
 * any overlap with existing methods?
+ * Check test failures with old-style (non-multi-db) settings file
+* custom_pk
+* backends
+ * Check test failures with MySQL MyISAM
+* serializers_regress
+* fixtures
+* lookup
+* transactions
+* model_regress
 
 Optional for v1.2
 ~

Modified: django/branches/soc2009/multidb/django/db/__init__.py
===
--- django/branches/soc2009/multidb/django/db/__init__.py   2009-11-23 
21:40:09 UTC (rev 11778)
+++ django/branches/soc2009/multidb/django/db/__init__.py   2009-11-26 
07:26:05 UTC (rev 11779)
@@ -17,9 +17,19 @@
 "settings.DATABASE_* is deprecated; use settings.DATABASES instead.",
 PendingDeprecationWarning
 )
+
+if settings.DATABASE_ENGINE in ("postgresql", "postgresql_psycopg2",
+"sqlite3", "mysql", "oracle"):
+engine = "django.db.backends.%s" % settings.DATABASE_ENGINE
+warnings.warn(
+"Short names for DATABASE_ENGINE are deprecated; prepend with 
'django.db.backends.'",
+PendingDeprecationWarning
+)
+else:
+engine = settings.DATABASE_ENGINE
 
 settings.DATABASES[DEFAULT_DB_ALIAS] = {
-'ENGINE': settings.DATABASE_ENGINE,
+'ENGINE': engine,
 'HOST': settings.DATABASE_HOST,
 'NAME': settings.DATABASE_NAME,
 'OPTIONS': settings.DATABASE_OPTIONS,

Modified: django/branches/soc2009/multidb/django/db/utils.py
===
--- django/branches/soc2009/multidb/django/db/utils.py  2009-11-23 21:40:09 UTC 
(rev 11778)
+++ django/branches/soc2009/multidb/django/db/utils.py  2009-11-26 07:26:05 UTC 
(rev 11779)
@@ -6,13 +6,7 @@
 
 def load_backend(backend_name):
 try:
-module = import_module('.base', 'django.db.backends.%s' % backend_name)
-import warnings
-warnings.warn(
-"Short names for DATABASE_ENGINE are deprecated; prepend with 
'django.db.backends.'",
-PendingDeprecationWarning
-)
-return module
+return import_module('.base', 'django.db.backends.%s' % backend_name)
 except ImportError, e:
 # Look for a fully qualified database backend name
 try:

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11918: Admin URLs troubles

[Django]

#11918: Admin URLs troubles
---+
  Reporter:  camilonova| Owner:  nobody
Status:  closed| Milestone:
 Component:  Contrib apps  |   Version:  1.1   
Resolution:  invalid   |  Keywords:  admin urls 404
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by toby...@gmail.com):

  * status:  reopened => closed
  * resolution:  => invalid
  * needs_tests:  1 => 0

Comment:

 Sorry, this is not a django issue the registration of models with the
 admin site should not live in models.py

 Taken from: http://groups.google.com/group/django-
 
users/browse_thread/thread/1e3ac5beaa4ab370/1fe62a0d92a6797e?lnk=gst&q=admin+urls+not+working+correctly#1fe62a0d92a6797e

 "You've put your admin.site.register call in models.py.  This should go
 in an admin.py file, not models.py.  Whether your model is registered with
 admin is being determined by the accident of whether your models.py file
 has
 happened to be loaded at the time you attempt to access it in admin.  Your
 models.py file will have been loaded when running under the development
 server, since it does explicit model validation during startup.  Similarly
 the admin validation done when DEBUG=True will have ensured that your
 models.py file is loaded when you first attempt to access admin.

 When running under Apache with DEBUG=False, however, there has not
 necessarily been any need to load your models.py by the time you attempt
 to
 access admin. That's why you are getting 404 errors...that call to
 admin.site.register has not yet been made.

 admin.autodiscover() and placing admin registrations in admin.py files
 (what
 are loaded by admin.autodiscover()) ensures that model registrations
 happen
 once and only once, at a predictable time, regardless of deployment
 scenario
 and debug setting.  If you move your admin registrations to an admin"

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11918: Admin URLs troubles

[Django]

#11918: Admin URLs troubles
---+
  Reporter:  camilonova| Owner:  nobody
Status:  reopened  | Milestone:
 Component:  Contrib apps  |   Version:  1.1   
Resolution:|  Keywords:  admin urls 404
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
Changes (by toby...@gmail.com):

  * status:  closed => reopened
  * component:  django-admin.py => Contrib apps
  * needs_tests:  0 => 1
  * version:  SVN => 1.1
  * keywords:  => admin urls 404
  * resolution:  invalid =>

Comment:

 Unfortunately camilonova didn't leave a very good description of the
 problem, I'm encountering this error and have found a few other people
 talking about it too.

 This is the first time, out of many django 1.1 deployments, that I have
 ever encountered this behaviour.

 The admin site works as expected for a while, and then randomly starts
 returning 404 whist browsing / editing content. I returned the exception
 data from handlers/base.py before it had a chance to render the 404 page
 and it turns out that django stops adding the urls for the installed
 apps... a few refreshes later and pages start re appearing.

 This only seems to happen when DEBUG is set to False meaning you never get
 any feedback on what urls django is matching against. The exception data
 isn't passed through to the 404 template.

 Something causes django to stop appending the installed models to the
 admin url patterns, I haven't managed to find a consistent method of
 replicating the problem, its just a case of clicking around until it
 starts throwing 404's.

 I read that someone managed to fix the issue by using the following:


 {{{
 from django.db import models
 models.get_apps()
 }}}

 in urls.py after calling admin.autodiscover(). I can't imagine how on
 earth it would help but im giving it a go because I haven't got anything
 else to go on!

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #12266: tutorial02: Error in fieldset data structure

[Django]

#12266: tutorial02: Error in fieldset data structure
---+
 Reporter:  roelschlaeger  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Running '1.2 pre-alpha' on Windows

 In http://docs.djangoproject.com/en/dev/intro/tutorial02/#intro-tutorial02

 {{{
 class PollAdmin(admin.ModelAdmin):
 fieldsets = [
 (None,   {'fields': ['question']}),
 ('Date information', {'fields': ['pub_date']}),
 ]

 admin.site.register(Poll, PollAdmin)
 }}}

 didn't work, but

 {{{
 class PollAdmin(admin.ModelAdmin):

 fieldsets = [
 (None,  {'fields': ('question',)}),
 ('Date Information',{'fields': ('pub_date',)}),
 ]

 admin.site.register(Poll, PollAdmin)
 }}}

 did.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12263: Mixed concerns between application and http caching

[Django]

#12263: Mixed concerns between application and http caching
---+
  Reporter:  sebbacon  | Owner:  nobody 

Status:  closed| Milestone: 

 Component:  Cache system  |   Version:  1.1

Resolution:  invalid   |  Keywords:  etag http headers 
last-modified
 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * status:  new => closed
  * needs_better_patch:  => 0
  * resolution:  => invalid
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 I'm going to close this invalid. Trac isn't for raising discussion points
 - that's why we have a django-dev mailing list.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12224: psycopg2 raises "can't adapt" when use gettext extensions on model meta permissions field.

[Django]

#12224: psycopg2 raises "can't adapt" when use gettext extensions on model meta
permissions field.
---+
  Reporter:  chronos   | Owner:  chronos

Status:  new   | Milestone:  1.2

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:|  Keywords:  psycopg2, 
permissions, i18n, gettext, "can't adapt", syncdb
 Stage:  Unreviewed| Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Changes (by chronos):

  * needs_better_patch:  => 0
  * has_patch:  0 => 1
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 With help of SmileyChris on #django-dev I fixed this problem forcing
 unicode with force_unicode (my original idea was use mark_safe). Similar
 fix was did Alex in #10616.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #4680: Fixes problem in initial_sql where "--" is in a string

[Django]

#4680: Fixes problem in initial_sql where "--" is in a string
--+-
  Reporter:  Tim Chase| Owner:  anonymous   
 
Status:  new  | Milestone:  
 
 Component:  django-admin.py  |   Version:  SVN 
 
Resolution:   |  Keywords:  initial-sql manage.py 
sprintdec01
 Stage:  Accepted | Has_patch:  1   
 
Needs_docs:  0|   Needs_tests:  0   
 
Needs_better_patch:  1|  
--+-
Comment (by anonymous):

 This seems to have been fixed in bug #6394.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #2495: db.models.TextField cannot be marked unique when using mysql backend

[Django]

#2495: db.models.TextField cannot be marked unique when using mysql backend
---+
  Reporter:  anonymous | Owner:  Honza_Kral 

Status:  new   | Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:|  Keywords:  mysql 
TextField
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Comment (by danny...@toldme.com):

 Hello,

 How do I replace the constraint with ALTER TABLE?

 My class boils down to:
 {{{
 class Tag(models.Model):
  name = models.TextField(max_length=32, primary_key=True)
  # Needed for syncdb.  See: http://code.djangoproject.com/ticket/2495
  #name = models.TextField(max_length=32)
 }}}

 So, I ran syncdb using the latter line, and it ran . . . now I'm in mysql
 . . .

 {{{
 mysql> describe events_tag;
 +---+--+--+-+-++
 | Field | Type | Null | Key | Default | Extra  |
 +---+--+--+-+-++
 | id| int(11)  | NO   | PRI | NULL| auto_increment |
 | name  | longtext | NO   | | NULL||
 +---+--+--+-+-++
 2 rows in set (0.01 sec)

 mysql> alter table events_tag add primary key(name);
 ERROR 1170 (42000): BLOB/TEXT column 'name' used in key specification
 without a key length
 mysql> alter table events_tag add unique key(name);
 ERROR 1170 (42000): BLOB/TEXT column 'name' used in key specification
 without a key length
 mysql> alter table events_tag add unique index(name);
 ERROR 1170 (42000): BLOB/TEXT column 'name' used in key specification
 without a key length
 }}}

 My main concern is that the tag name be unique.  Do I have to set that in
 MySQL, or will Django enforce this for me, or do I have to implement this
 check within the class?  (I already have a save method which does some
 sanity checking before a new tag can be added, so throwing a duplicate
 check in there aint a big deal . . .)

 Thanks!

 Sincerely,
 -daniel

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12265: Media (js/css) collection strategy in Forms has no order dependence concept

[Django]

#12265: Media (js/css) collection strategy in Forms has no order dependence 
concept
-+--
  Reporter:  tblanch...@mac.com  | Owner:  nobody
Status:  new | Milestone:
 Component:  Forms   |   Version:  1.1   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by Alex):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

Old description:

> And thus is broken.  I have a form with a bunch of fields in it and when
> collecting the js files to include it mixes up the order and thus core.js
> ends up loaded later than files that require addEvent and the js load
> fails.  At the end of the day, this mechanism is just half baked and
> would be better removed entirely so busy developers can just get stuff
> done and not waste time with it.
>
> For example:
>
> class NewIncidentForm(forms.ModelForm):
> place = forms.CharField(widget=EditableMap(options={
> 'layers': ['google.hybrid', 'google.streets', 'google.physical',
> 'google.satellite',  ],
> 'default_lat': 39.4421,
> 'default_lon': -100.0,
> 'default_zoom': 7,
> 'geometry': 'point',
> }))
> when_occurred =
> forms.DateTimeField(widget=widgets.AdminSplitDateTime())
> when_reported =
> forms.DateTimeField(widget=widgets.AdminSplitDateTime())
>
> class Meta:
> model = Incident
>
> class Media:
> js = (  '/media/js/core.js',
> '/media/js/admin/RelatedObjectLookups.js',
> '/media/js/getElementsBySelector.js',
> '/media/js/actions.js', )
>
> class Incident(models.Model):
>
> title = models.CharField(max_length=128)
> when_occurred = models.DateTimeField()
> when_reported = models.DateTimeField()
> reporter = models.ForeignKey(User)
> place = models.PointField()
> notes = models.TextField(max_length=4000)
> what_type = models.ForeignKey(IncidentType)
>
> # allow spatial querying
> objects = models.GeoManager()
>

>
> results in this:
>
> media="all" rel="stylesheet" />
> 
>  src="/media/js/admin/DateTimeShortcuts.js">
>  src="http://openlayers.org/api/2.8/OpenLayers.js";>
>  src="/static/olwidget/js/olwidget.js">
>  src="http://maps.google.com/maps?file=api&v=2&key=ABQIWGazslnMSgtzbIMfXLHIgBS5ci6sQZUkD9hfwKAiXgiJK2N7uxTWbLDcob2apHjRnK6OlA7hReqQaA";>
> 
>  src="/media/js/admin/RelatedObjectLookups.js">
>  src="/media/js/getElementsBySelector.js">
> 
>
> which fails because DateTimeShortcuts requires addEvent which is defined
> in core.js

New description:

 And thus is broken.  I have a form with a bunch of fields in it and when
 collecting the js files to include it mixes up the order and thus core.js
 ends up loaded later than files that require addEvent and the js load
 fails.  At the end of the day, this mechanism is just half baked and would
 be better removed entirely so busy developers can just get stuff done and
 not waste time with it.

 For example:
 {{{
 class NewIncidentForm(forms.ModelForm):
 place = forms.CharField(widget=EditableMap(options={
 'layers': ['google.hybrid', 'google.streets', 'google.physical',
 'google.satellite',  ],
 'default_lat': 39.4421,
 'default_lon': -100.0,
 'default_zoom': 7,
 'geometry': 'point',
 }))
 when_occurred =
 forms.DateTimeField(widget=widgets.AdminSplitDateTime())
 when_reported =
 forms.DateTimeField(widget=widgets.AdminSplitDateTime())

 class Meta:
 model = Incident

 class Media:
 js = (  '/media/js/core.js',
 '/media/js/admin/RelatedObjectLookups.js',
 '/media/js/getElementsBySelector.js',
 '/media/js/actions.js', )

 class Incident(models.Model):

 title = models.CharField(max_length=128)
 when_occurred = models.DateTimeField()
 when_reported = models.DateTimeField()
 reporter = models.ForeignKey(User)
 place = models.PointField()
 notes = models.TextField(max_length=4000)
 what_type = models.ForeignKey(IncidentType)

 # allow spatial querying
 objects = models.GeoManager()

 }}}

 results in this:
 {{{

 
 
 http://openlayers.org/api/2.8/OpenLayers.js";>
 
 http://maps.google.com/maps?file=api&v=2&key=ABQIWGazslnMSgtzbIMfXLHIgBS5ci6sQZUkD9hfwKAiXgiJK2N7uxTWbLDcob2apHjRnK6OlA

[Django] #12265: Media (js/css) collection strategy in Forms has no order dependence concept

[Django]

#12265: Media (js/css) collection strategy in Forms has no order dependence 
concept
+---
 Reporter:  tblanch...@mac.com  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Forms   | Version:  1.1   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 And thus is broken.  I have a form with a bunch of fields in it and when
 collecting the js files to include it mixes up the order and thus core.js
 ends up loaded later than files that require addEvent and the js load
 fails.  At the end of the day, this mechanism is just half baked and would
 be better removed entirely so busy developers can just get stuff done and
 not waste time with it.

 For example:

 class NewIncidentForm(forms.ModelForm):
 place = forms.CharField(widget=EditableMap(options={
 'layers': ['google.hybrid', 'google.streets', 'google.physical',
 'google.satellite',  ],
 'default_lat': 39.4421,
 'default_lon': -100.0,
 'default_zoom': 7,
 'geometry': 'point',
 }))
 when_occurred =
 forms.DateTimeField(widget=widgets.AdminSplitDateTime())
 when_reported =
 forms.DateTimeField(widget=widgets.AdminSplitDateTime())

 class Meta:
 model = Incident

 class Media:
 js = (  '/media/js/core.js',
 '/media/js/admin/RelatedObjectLookups.js',
 '/media/js/getElementsBySelector.js',
 '/media/js/actions.js', )

 class Incident(models.Model):

 title = models.CharField(max_length=128)
 when_occurred = models.DateTimeField()
 when_reported = models.DateTimeField()
 reporter = models.ForeignKey(User)
 place = models.PointField()
 notes = models.TextField(max_length=4000)
 what_type = models.ForeignKey(IncidentType)

 # allow spatial querying
 objects = models.GeoManager()



 results in this:


 
 
 http://openlayers.org/api/2.8/OpenLayers.js";>
 
 http://maps.google.com/maps?file=api&v=2&key=ABQIWGazslnMSgtzbIMfXLHIgBS5ci6sQZUkD9hfwKAiXgiJK2N7uxTWbLDcob2apHjRnK6OlA7hReqQaA";>
 
 
 
 

 which fails because DateTimeShortcuts requires addEvent which is defined
 in core.js

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #12264: calendar.js depends on jsi18n but date widgets using it do not specify as required media

[Django]

#12264: calendar.js depends on jsi18n but date widgets using it do not specify 
as
required media
+---
 Reporter:  tblanch...@mac.com  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Forms   | Version:  1.1   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 Its nice that we can just use the admin widgets in our own public forms -
 except trying to include the split date/time widget results in a need for
 gettext which is in the jsi18n package which requires a separate urlconf
 entry and view to pull into my app.  This is messy.  Dependent code should
 automatically pull in its dependencies.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #9308: Django fails to set nullable foreign key field to NULL before deleting the referenced record

[Django]

#9308: Django fails to set nullable foreign key field to NULL before deleting 
the
referenced record
---+
  Reporter:  egenix_viktor | Owner:  nobody 
   
Status:  closed| Milestone:  1.1
   
 Component:  Database layer (models, ORM)  |   Version:  1.0
   
Resolution:  fixed |  Keywords:  delete 
record foreign key constraint check NULL nullable field
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Comment (by libraM):

 See also

http://stackoverflow.com/questions/1006135/how-do-i-create-a-django-
 model-with-foreignkeys-which-does-not-cascade-deletes-to

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #10761: ModelAdmin.queryset() is missing a mechanism for specifying different querysets for changelist and change object views

[Django]

#10761: ModelAdmin.queryset() is missing a mechanism for specifying different
querysets for changelist and change object views
---+
  Reporter:  mrts  | Owner:  nobody 
Status:  new   | Milestone:  1.2
 Component:  django.contrib.admin  |   Version:  SVN
Resolution:|  Keywords:  efficient-admin
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by marcob):

 * cc: marcob...@gmail.com (added)

Comment:

 Besides queryset, I would also like to have an hook to customize, for
 example, list_display and list_filter in a cleaner way than this (mine
 ugly code follows):

 {{{
 def category_changelist_view(self, request, extra_context=None,
 category=None):
 backup_list_filter = self.list_filter[:]
 backup_list_display = self.list_display[:]
 backup_queryset = self.queryset

 self.list_filter = None
 self.list_display.remove('category')
 self.queryset = curry(self.category_queryset, category=category)

 ret = super(PVCataAdmin, self).changelist_view(request,
 extra_context)

 self.list_filter = backup_list_filter
 self.list_display = backup_list_display
 self.queryset = backup_queryset

 return ret

 def get_urls(self):
 urls = super(CategoryAdmin, self).get_urls()
 urls_categories = patterns('',
 *tuple(
 ((r'%s/$' % categories), self.admin_site.admin_view(
 curry(self.categories_changelist_view,
 category=category.pk)))
 for category in Category.objects.all())
 )
 return urls_categories + urls

 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #12263: Mixed concerns between application and http caching

[Django]

#12263: Mixed concerns between application and http caching
-+--
 Reporter:  sebbacon |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Cache system | Version:  1.1   
 Keywords:  etag http headers last-modified  |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 I've found the treatment of HTTP cache headers in Django counterintuitive.
 I'm not sure if the code or the documentation needs fixing, so this is
 more a discussion point than a bug.

 The cache middleware (in {{django.middleware.cache}} is for caching
 objects in memory.  As a side-effect, it also sets ETag and Last-Modified
 dates.

 1) I view this as a bug, as it's mixing two concerns -- application-level
 caching and HTTP caching.  It certainly threw me when trying to debug some
 HTTP caching issues, as it interacts in unexpected ways with Django's
 explicit HTTP caching facilities such as the {{cache_control}}} decorator.

 2) I'd rather HTTP caching was controlled completely separately, but if
 not, shouldn't this behaviour honour the USE_ETAGS setting that's used in
 {{django.middleware.CommonMiddleware}}?

 3) Also, if it's considered that HTTP caching should be set at the same
 time as app caching, should we consider noting in the comments that the
 ConditionalGetMiddleware should be enabled if the server is to honour
 these headers?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.