[Django] #9417: Unhelpful admin.py error message

[Django]

#9417: Unhelpful admin.py error message
--+-
 Reporter:  dwillis   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 If you make a boneheaded move such as creating a ModelAdmin class for a
 model that you forgot to include in your admin.py's model import
 statement, you get an error. But it's not the error you might expect. What
 happens is you get the "model already registered exception", citing the
 first model registered using admin.site.register().

 I spent awhile looking around my app trying to see if I had indeed
 registered the model in question more than once via imports, but couldn't
 find it. When I fixed my error in the import statement, everything was
 fine.

 So definitely user error. But the error message Django displayed didn't
 help guide me to the problem.

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9415: QuerySet.order_by() should be chainable

[Django]

#9415: QuerySet.order_by() should be chainable
---+
  Reporter:  Tarken| Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:  wontfix   |  Keywords:
 Stage:  Design decision needed| Has_patch:  1 
Needs_docs:  1 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 No, the current behaviour is deliberate. The reason is that chaining for
 ordering would actually behave very counter-intuitively, since ordering is
 left-to-right sensitive in terms of "most significant" to "least
 significant". Things added after the initial ordering end up having almost
 no effect on the result, because the leading ordering terms dominate.

 I don't see it as really common enough that the major ordering is going to
 be added in one place and minor tweaking of the far right, inisignificant
 terms will happen later that it's worth complicating the UI here.

 A docs patch would be fine (in another ticket so that we can review it in
 isolation), but the current behaviour is quite intentional and it would be
 counter-productive to change it.

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9416: fLatpages Setup Instructions ~ incomplete?

[Django]

#9416: fLatpages Setup Instructions ~ incomplete?
---+
 Reporter:  antonius   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 flatpages docs should make reference to 'SITE_ID' being correct
 (settings.py)

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9383: skip mail_admins/mail_managers if ADMINS or MANAGERS is empty

[Django]

#9383: skip mail_admins/mail_managers if ADMINS or MANAGERS is empty
-+--
  Reporter:  adunar  | Owner:  nobody   
Status:  new | Milestone:  post-1.0 
 Component:  Core framework  |   Version:  1.0  
Resolution:  |  Keywords:  500 error mail_admins
 Stage:  Accepted| Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by adunar):

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

Comment:

 okay, my new diff includes a regression test that fails before and passes
 after, as well as a minor update to the documentation for mail_admins.

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9415: QuerySet.order_by() should be chainable

[Django]

#9415: QuerySet.order_by() should be chainable
---+
  Reporter:  Tarken| Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Design decision needed| Has_patch:  1 
Needs_docs:  1 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by anonymous):

 To get around this until the patch lands, we currently have an ordering =
 [] set and as the orderings are picked up append to ordering. The final
 step is then qset = qset.order_by(*ordering).

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9111: form error get escaped on _html_output even if it is a SafeString instance

[Django]

#9111: form error get escaped on _html_output even if it is a SafeString 
instance
---+
  Reporter:  michelts  | Owner:  kratorius  
   
Status:  new   | Milestone: 
   
 Component:  Forms |   Version:  1.0
   
Resolution:|  Keywords:  form error escape safestring 
mark_safe
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by adunar):

 * cc: adunar (added)

Comment:

 As I noted on http://groups.google.com/group/django-
 developers/browse_thread/thread/86fd952b0efc641e , mark_safe should also
 work on labels of form fields. I've updated the patch to also call
 conditional_escape on form labels, and added a regression test for that.

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9408: Oracle backend, error in FormatStylePlaceholderCursor _format_params method

[Django]

#9408: Oracle backend, error in FormatStylePlaceholderCursor _format_params 
method
---+
  Reporter:  ramiro| Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:|  Keywords:  oracle 
_format_params
 Stage:  Unreviewed| Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

  * version:  1.0 => SVN
  * summary:  Oracle backend, error in Oracle's
  FormatStylePlaceholderCursor _format_params
  method => Oracle backend, error in
  FormatStylePlaceholderCursor _format_params
  method

Old description:

> This was been reported in passing in the #5543 attachment comment but it
> can ba fixed independently so I'm reporting it here just inc ase it' a
> real problem.

New description:

 This was reported in passing in the #5543 attachment comment but it can be
 fixed independently so I'm reporting it here just in case it's a real
 problem.

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8907: ORM-level Caching

[Django]

#8907: ORM-level Caching
-+--
  Reporter:  bradcater   | Owner:  anonymous
Status:  assigned| Milestone:  post-1.0 
 Component:  Cache system|   Version:  1.0  
Resolution:  |  Keywords:   
 Stage:  Design decision needed  | Has_patch:  1
Needs_docs:  0   |   Needs_tests:  1
Needs_better_patch:  0   |  
-+--
Comment (by kmtracey):

 Trac isn't displaying it properly, probably because it is a simple diff of
 a single file instead of an svn diff from the root of the source tree.
 You can still see if if you follow the link to "download in original
 format", it's just harder.

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8907: ORM-level Caching

[Django]

#8907: ORM-level Caching
-+--
  Reporter:  bradcater   | Owner:  anonymous
Status:  assigned| Milestone:  post-1.0 
 Component:  Cache system|   Version:  1.0  
Resolution:  |  Keywords:   
 Stage:  Design decision needed  | Has_patch:  1
Needs_docs:  0   |   Needs_tests:  1
Needs_better_patch:  0   |  
-+--
Comment (by PhiR):

 patch is broken ? can't see from here

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8882: Inline model formsets break validation for unique and unique_together with foreign keys

[Django]

#8882: Inline model formsets break validation for unique and unique_together 
with
foreign keys
--+-
  Reporter:  [EMAIL PROTECTED]  | Owner:  brosner 
Status:  assigned | Milestone:  
 Component:  Forms|   Version:  1.0 
Resolution:   |  Keywords:  model-validation
 Stage:  Accepted | Has_patch:  0   
Needs_docs:  0|   Needs_tests:  0   
Needs_better_patch:  0|  
--+-
Changes (by brosner):

  * owner:  nobody => brosner
  * status:  new => assigned

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9243 - in django/trunk/django/contrib/admin: . templates/admin/edit_inline

[noreply]

Author: brosner
Date: 2008-10-21 15:25:45 -0500 (Tue, 21 Oct 2008)
New Revision: 9243

Modified:
   django/trunk/django/contrib/admin/helpers.py
   django/trunk/django/contrib/admin/options.py
   django/trunk/django/contrib/admin/templates/admin/edit_inline/stacked.html
   django/trunk/django/contrib/admin/templates/admin/edit_inline/tabular.html
Log:
Display non_field_errors of inline forms in the admin. This was a presentation 
bug.

Modified: django/trunk/django/contrib/admin/helpers.py
===
--- django/trunk/django/contrib/admin/helpers.py2008-10-21 19:06:44 UTC 
(rev 9242)
+++ django/trunk/django/contrib/admin/helpers.py2008-10-21 20:25:45 UTC 
(rev 9243)
@@ -129,6 +129,16 @@
 self.original.content_type_id = 
ContentType.objects.get_for_model(original).pk
 self.show_url = original and hasattr(original, 'get_absolute_url')
 super(InlineAdminForm, self).__init__(form, fieldsets, 
prepopulated_fields)
+
+def field_count(self):
+# tabular.html uses this function for colspan value.
+num_of_fields = 1 # always has at least one field
+num_of_fields += len(self.fieldsets[0][1]["fields"])
+if self.formset.can_order:
+num_of_fields += 1
+if self.formset.can_delete:
+num_of_fields += 1
+return num_of_fields
 
 def pk_field(self):
 return AdminField(self.form, self.formset._pk_field.name, False)

Modified: django/trunk/django/contrib/admin/options.py
===
--- django/trunk/django/contrib/admin/options.py2008-10-21 19:06:44 UTC 
(rev 9242)
+++ django/trunk/django/contrib/admin/options.py2008-10-21 20:25:45 UTC 
(rev 9243)
@@ -585,6 +585,7 @@
 change_message = self.construct_change_message(request, form, 
formsets)
 self.log_change(request, new_object, change_message)
 return self.response_change(request, new_object)
+
 else:
 form = ModelForm(instance=obj)
 for FormSet in self.get_formsets(request, obj):
@@ -600,7 +601,7 @@
 inline_admin_formset = helpers.InlineAdminFormSet(inline, formset, 
fieldsets)
 inline_admin_formsets.append(inline_admin_formset)
 media = media + inline_admin_formset.media
-
+
 context = {
 'title': _('Change %s') % force_unicode(opts.verbose_name),
 'adminform': adminForm,

Modified: 
django/trunk/django/contrib/admin/templates/admin/edit_inline/stacked.html
===
--- django/trunk/django/contrib/admin/templates/admin/edit_inline/stacked.html  
2008-10-21 19:06:44 UTC (rev 9242)
+++ django/trunk/django/contrib/admin/templates/admin/edit_inline/stacked.html  
2008-10-21 20:25:45 UTC (rev 9243)
@@ -12,6 +12,7 @@
   {% if inline_admin_form.show_url %}
   {% trans "View on site" %}
   {% endif %}
+  {% if inline_admin_form.form.non_field_errors %}{{ 
inline_admin_form.form.non_field_errors }}{% endif %}
 
   {% for fieldset in inline_admin_form %}
 {% include "admin/includes/fieldset.html" %}

Modified: 
django/trunk/django/contrib/admin/templates/admin/edit_inline/tabular.html
===
--- django/trunk/django/contrib/admin/templates/admin/edit_inline/tabular.html  
2008-10-21 19:06:44 UTC (rev 9242)
+++ django/trunk/django/contrib/admin/templates/admin/edit_inline/tabular.html  
2008-10-21 20:25:45 UTC (rev 9243)
@@ -16,7 +16,9 @@
  

  {% for inline_admin_form in inline_admin_formset %}
-   
+{% if inline_admin_form.form.non_field_errors %}
+{{ 
inline_admin_form.form.non_field_errors }}
+{% endif %}
 
 
 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9415: QuerySet.order_by() should be chainable

[Django]

#9415: QuerySet.order_by() should be chainable
---+
  Reporter:  Tarken| Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Design decision needed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by Alex):

 FWIW the code changes needed would be VERY minimal once a good API is
 determined.

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9415: QuerySet.order_by() should be chainable

[Django]

#9415: QuerySet.order_by() should be chainable
---+
  Reporter:  Tarken| Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Design decision needed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Alex):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Design decision needed
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 having them just chainable by default would be backwards incompatible, so
 it really can't be done, however perhaps their could be a kwarg to tell
 order_by not to remove the previous ordering(reset=False perhaps?).

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9415: QuerySet.order_by() should be chainable

[Django]

#9415: QuerySet.order_by() should be chainable
--+-
 Reporter:  Tarken|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I have a case where it would be very convenient to be able to call
 order_by() multiple times, appending to the order by clause with each
 successive call; i.e.,
 {{{
 #!python
 foo = Model.objects.all().order_by('field1')
 if bar:
 foo = foo.order_by('-field2')
 }}}
 Currently, the second call to order_by() explicitly overrides the previous
 order. This is not the behavior I would expect, as most (all?) other
 methods on a QuerySet are chainable.

 If it is decided that chaining will not be allowed with order_by(), then I
 think that this fact should at least be documented. Had I not been
 printing out my connection's queries when I ran into this problem, it may
 have taken me some time to figure out exactly what was going 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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8916: admin auth change password not working

[Django]

#8916: admin auth change password not working
---+
  Reporter:  [EMAIL PROTECTED]| Owner:  nobody
Status:  closed| Milestone:
 Component:  django.contrib.admin  |   Version:  1.0   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by [EMAIL PROTECTED]):

 I am getting this same error on 2 unrelated sites I just recently upgraded
 to django 1.0.  I don't have any admin class registered with my user model
 on either site, only:
 {{{
 admin_site = admin.AdminSite()
 admin_site.register(User)
 }}}

 I tried importing the UserAdmin as recommended above and registering with
 the User model to the admin site, but I am still getting the error
 described above on 2 sites I've tested now:
 {{{
 Environment:

 Request Method: GET
 Request URL: http://aaronfay.ca/admin/auth/user/1/password/
 Django Version: 1.0-final-SVN-unknown
 Python Version: 2.5.1
 Installed Applications:
 ['django.contrib.admin',
  'django.contrib.auth',
  'django.contrib.comments',
  'django.contrib.contenttypes',
  'django.contrib.markup',
  'django.contrib.sessions',
  'django.contrib.sites',
  'common',
  'region',
  'profile',
  'tagging']
 Installed Middleware:
 ('django.middleware.common.CommonMiddleware',
  'django.contrib.sessions.middleware.SessionMiddleware',
  'django.contrib.auth.middleware.AuthenticationMiddleware',
  'django.middleware.doc.XViewMiddleware',
  'middleware.StatsMiddleware')


 Traceback:
 File
 "/home/aaronfay/webapps/aaronfay/lib/python2.5/django/core/handlers/base.py"
 in get_response
   81. response = middleware_method(request, callback,
 callback_args, callback_kwargs)
 File "/home/aaronfay/webapps/aaronfay/aaronfay/middleware.py" in
 process_view
   20. response = view_func(request, *view_args, **view_kwargs)
 File
 "/home/aaronfay/webapps/aaronfay/lib/python2.5/django/contrib/admin/sites.py"
 in root
   158. return self.model_page(request, *url.split('/', 2))
 File
 
"/home/aaronfay/webapps/aaronfay/lib/python2.5/django/views/decorators/cache.py"
 in _wrapped_view_func
   44. response = view_func(request, *args, **kwargs)
 File
 "/home/aaronfay/webapps/aaronfay/lib/python2.5/django/contrib/admin/sites.py"
 in model_page
   177. return admin_obj(request, rest_of_url)
 File
 "/home/aaronfay/webapps/aaronfay/lib/python2.5/django/contrib/admin/options.py"
 in __call__
   197. return self.change_view(request, unquote(url))
 File
 "/home/aaronfay/webapps/aaronfay/lib/python2.5/django/db/transaction.py"
 in _commit_on_success
   238. res = func(*args, **kw)
 File
 "/home/aaronfay/webapps/aaronfay/lib/python2.5/django/contrib/admin/options.py"
 in change_view
   557. obj = model._default_manager.get(pk=object_id)
 File
 "/home/aaronfay/webapps/aaronfay/lib/python2.5/django/db/models/manager.py"
 in get
   93. return self.get_query_set().get(*args, **kwargs)
 File
 "/home/aaronfay/webapps/aaronfay/lib/python2.5/django/db/models/query.py"
 in get
   297. clone = self.filter(*args, **kwargs)
 File
 "/home/aaronfay/webapps/aaronfay/lib/python2.5/django/db/models/query.py"
 in filter
   483. return self._filter_or_exclude(False, *args, **kwargs)
 File
 "/home/aaronfay/webapps/aaronfay/lib/python2.5/django/db/models/query.py"
 in _filter_or_exclude
   501. clone.query.add_q(Q(*args, **kwargs))
 File
 "/home/aaronfay/webapps/aaronfay/lib/python2.5/django/db/models/sql/query.py"
 in add_q
   1224. can_reuse=used_aliases)
 File
 "/home/aaronfay/webapps/aaronfay/lib/python2.5/django/db/models/sql/query.py"
 in add_filter
   1167. self.where.add((alias, col, field, lookup_type, value),
 connector)
 File
 "/home/aaronfay/webapps/aaronfay/lib/python2.5/django/db/models/sql/where.py"
 in add
   48. params = field.get_db_prep_lookup(lookup_type,
 value)
 File
 
"/home/aaronfay/webapps/aaronfay/lib/python2.5/django/db/models/fields/__init__.py"
 in get_db_prep_lookup
   202. return [self.get_db_prep_value(value)]
 File
 
"/home/aaronfay/webapps/aaronfay/lib/python2.5/django/db/models/fields/__init__.py"
 in get_db_prep_value
   353. return int(value)

 Exception Type: ValueError at /admin/auth/user/1/password/
 Exception Value: invalid literal for int() with base 10: '1/password'

 }}}

 I'm not certain I should reopen the ticket, but I wanted to let you know I
 am getting the error also.  The 2 sites I tested are on 2 separate
 servers, both with Django 1.0 release.

-- 
Ticket URL: 

[Django] #9414: Documentation on has_perm and the permission_required decorator is confusing

[Django]

#9414: Documentation on has_perm and the permission_required decorator is
confusing
---+
 Reporter:  wallenfe   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The documentation on using has_perm and permission_required is confusing
 in that it does not define how the permission string that is passed to
 those functions is defined.

 The documentation should mention that the string is:
 ApplicationName.PermissionName.

 Since Permissions are defined on models, my first inclination was to try:
 ModelName.PermissionName


 This is the documentation page I am referring to:
 http://docs.djangoproject.com/en/dev/topics/auth/#topics-auth

 And an example of the permission string being used, but without an
 explanation.
 "
 def my_view(request):
 if not (request.user.is_authenticated() and
 request.user.has_perm('polls.can_vote')):
 "

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8633: Field default value force to unicode when create custom field.

[Django]

#8633: Field default value force to unicode when create custom field.
---+
  Reporter:  flytwokites   | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by carljm):

 Just to document this further for anybody else who stumbles across this:
 the "mistake" here is in setting a Field's default value to any mutable
 object (a Hand instance, a list, a set, whatever). This is almost
 certainly not what you want to do, as a reference to the same _instance_
 of that object would be used as the default value for that field in all
 new model instances.  So Django instead forces that default value to
 unicode, which is immutable.

 The correct approach is to instead use as the default a callable that
 returns a Hand instance (or list, or set, or whatever).

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9242 - in django/branches/releases/1.0.X: . django/contrib/admin tests/regressiontests/admin_views tests/regressiontests/admin_views/fixtures

[noreply]

Author: kmtracey
Date: 2008-10-21 14:06:44 -0500 (Tue, 21 Oct 2008)
New Revision: 9242

Added:
   
django/branches/releases/1.0.X/tests/regressiontests/admin_views/fixtures/admin-views-colors.xml
Modified:
   django/branches/releases/1.0.X/
   django/branches/releases/1.0.X/django/contrib/admin/filterspecs.py
   django/branches/releases/1.0.X/tests/regressiontests/admin_views/models.py
   django/branches/releases/1.0.X/tests/regressiontests/admin_views/tests.py
Log:
[1.0.X] Fixed #3096 -- Make admin list_filters respect limit_choices_to.

Backport of [9241] from trunk.



Property changes on: django/branches/releases/1.0.X
___
Name: svnmerge-integrated
   - 
/django/trunk:1-9097,9099-9102,9104-9109,9111,9113-9144,9146-9151,9153-9156,9158-9159,9161-9187,9189-9239
   + 
/django/trunk:1-9097,9099-9102,9104-9109,9111,9113-9144,9146-9151,9153-9156,9158-9159,9161-9187,9189-9241

Modified: django/branches/releases/1.0.X/django/contrib/admin/filterspecs.py
===
--- django/branches/releases/1.0.X/django/contrib/admin/filterspecs.py  
2008-10-21 19:03:21 UTC (rev 9241)
+++ django/branches/releases/1.0.X/django/contrib/admin/filterspecs.py  
2008-10-21 19:06:44 UTC (rev 9242)
@@ -60,7 +60,7 @@
 self.lookup_title = f.verbose_name
 self.lookup_kwarg = '%s__%s__exact' % (f.name, f.rel.to._meta.pk.name)
 self.lookup_val = request.GET.get(self.lookup_kwarg, None)
-self.lookup_choices = f.rel.to._default_manager.all()
+self.lookup_choices = f.get_choices(include_blank=False)
 
 def has_output(self):
 return len(self.lookup_choices) > 1
@@ -72,8 +72,7 @@
 yield {'selected': self.lookup_val is None,
'query_string': cl.get_query_string({}, [self.lookup_kwarg]),
'display': _('All')}
-for val in self.lookup_choices:
-pk_val = getattr(val, self.field.rel.to._meta.pk.attname)
+for pk_val, val in self.lookup_choices:
 yield {'selected': self.lookup_val == smart_unicode(pk_val),
'query_string': cl.get_query_string({self.lookup_kwarg: 
pk_val}),
'display': val}

Copied: 
django/branches/releases/1.0.X/tests/regressiontests/admin_views/fixtures/admin-views-colors.xml
 (from rev 9241, 
django/trunk/tests/regressiontests/admin_views/fixtures/admin-views-colors.xml)
===
--- 
django/branches/releases/1.0.X/tests/regressiontests/admin_views/fixtures/admin-views-colors.xml
(rev 0)
+++ 
django/branches/releases/1.0.X/tests/regressiontests/admin_views/fixtures/admin-views-colors.xml
2008-10-21 19:06:44 UTC (rev 9242)
@@ -0,0 +1,19 @@
+
+
+
+Red
+1
+
+
+Orange
+1
+
+
+Blue
+0
+
+
+Green
+0
+
+

Modified: 
django/branches/releases/1.0.X/tests/regressiontests/admin_views/models.py
===
--- django/branches/releases/1.0.X/tests/regressiontests/admin_views/models.py  
2008-10-21 19:03:21 UTC (rev 9241)
+++ django/branches/releases/1.0.X/tests/regressiontests/admin_views/models.py  
2008-10-21 19:06:44 UTC (rev 9242)
@@ -74,7 +74,24 @@
 def __unicode__(self):
 return self.id
 
+class Color(models.Model):
+value = models.CharField(max_length=10)
+warm = models.BooleanField()   
+def __unicode__(self):
+return self.value
+
+class Thing(models.Model):
+title = models.CharField(max_length=20)
+color = models.ForeignKey(Color, limit_choices_to={'warm': True})
+def __unicode__(self):
+return self.title
+
+class ThingAdmin(admin.ModelAdmin):
+list_filter = ('color',)
+
 admin.site.register(Article, ArticleAdmin)
 admin.site.register(CustomArticle, CustomArticleAdmin)
 admin.site.register(Section, inlines=[ArticleInline])
 admin.site.register(ModelWithStringPrimaryKey)
+admin.site.register(Color)
+admin.site.register(Thing, ThingAdmin)

Modified: 
django/branches/releases/1.0.X/tests/regressiontests/admin_views/tests.py
===
--- django/branches/releases/1.0.X/tests/regressiontests/admin_views/tests.py   
2008-10-21 19:03:21 UTC (rev 9241)
+++ django/branches/releases/1.0.X/tests/regressiontests/admin_views/tests.py   
2008-10-21 19:06:44 UTC (rev 9242)
@@ -12,7 +12,7 @@
 from models import Article, CustomArticle, Section, ModelWithStringPrimaryKey
 
 class AdminViewBasicTest(TestCase):
-fixtures = ['admin-views-users.xml']
+fixtures = ['admin-views-users.xml', 'admin-views-colors.xml']
 
 def setUp(self):
 self.client.login(username='super', password='secret')
@@ -147,6 +147,19 @@
 response.content.index('Middle content') < 
response.content.index('Newest 

[Changeset] r9241 - in django/trunk: django/contrib/admin tests/regressiontests/admin_views tests/regressiontests/admin_views/fixtures

[noreply]

Author: kmtracey
Date: 2008-10-21 14:03:21 -0500 (Tue, 21 Oct 2008)
New Revision: 9241

Added:
   
django/trunk/tests/regressiontests/admin_views/fixtures/admin-views-colors.xml
Modified:
   django/trunk/django/contrib/admin/filterspecs.py
   django/trunk/tests/regressiontests/admin_views/models.py
   django/trunk/tests/regressiontests/admin_views/tests.py
Log:
Fixed #3096 -- Make admin list_filters respect limit_choices_to.


Modified: django/trunk/django/contrib/admin/filterspecs.py
===
--- django/trunk/django/contrib/admin/filterspecs.py2008-10-21 14:07:36 UTC 
(rev 9240)
+++ django/trunk/django/contrib/admin/filterspecs.py2008-10-21 19:03:21 UTC 
(rev 9241)
@@ -60,7 +60,7 @@
 self.lookup_title = f.verbose_name
 self.lookup_kwarg = '%s__%s__exact' % (f.name, f.rel.to._meta.pk.name)
 self.lookup_val = request.GET.get(self.lookup_kwarg, None)
-self.lookup_choices = f.rel.to._default_manager.all()
+self.lookup_choices = f.get_choices(include_blank=False)
 
 def has_output(self):
 return len(self.lookup_choices) > 1
@@ -72,8 +72,7 @@
 yield {'selected': self.lookup_val is None,
'query_string': cl.get_query_string({}, [self.lookup_kwarg]),
'display': _('All')}
-for val in self.lookup_choices:
-pk_val = getattr(val, self.field.rel.to._meta.pk.attname)
+for pk_val, val in self.lookup_choices:
 yield {'selected': self.lookup_val == smart_unicode(pk_val),
'query_string': cl.get_query_string({self.lookup_kwarg: 
pk_val}),
'display': val}

Added: 
django/trunk/tests/regressiontests/admin_views/fixtures/admin-views-colors.xml
===
--- 
django/trunk/tests/regressiontests/admin_views/fixtures/admin-views-colors.xml  
(rev 0)
+++ 
django/trunk/tests/regressiontests/admin_views/fixtures/admin-views-colors.xml  
2008-10-21 19:03:21 UTC (rev 9241)
@@ -0,0 +1,19 @@
+
+
+
+Red
+1
+
+
+Orange
+1
+
+
+Blue
+0
+
+
+Green
+0
+
+


Property changes on: 
django/trunk/tests/regressiontests/admin_views/fixtures/admin-views-colors.xml
___
Name: svn:eol-style
   + native

Modified: django/trunk/tests/regressiontests/admin_views/models.py
===
--- django/trunk/tests/regressiontests/admin_views/models.py2008-10-21 
14:07:36 UTC (rev 9240)
+++ django/trunk/tests/regressiontests/admin_views/models.py2008-10-21 
19:03:21 UTC (rev 9241)
@@ -74,7 +74,24 @@
 def __unicode__(self):
 return self.id
 
+class Color(models.Model):
+value = models.CharField(max_length=10)
+warm = models.BooleanField()   
+def __unicode__(self):
+return self.value
+
+class Thing(models.Model):
+title = models.CharField(max_length=20)
+color = models.ForeignKey(Color, limit_choices_to={'warm': True})
+def __unicode__(self):
+return self.title
+
+class ThingAdmin(admin.ModelAdmin):
+list_filter = ('color',)
+
 admin.site.register(Article, ArticleAdmin)
 admin.site.register(CustomArticle, CustomArticleAdmin)
 admin.site.register(Section, inlines=[ArticleInline])
 admin.site.register(ModelWithStringPrimaryKey)
+admin.site.register(Color)
+admin.site.register(Thing, ThingAdmin)

Modified: django/trunk/tests/regressiontests/admin_views/tests.py
===
--- django/trunk/tests/regressiontests/admin_views/tests.py 2008-10-21 
14:07:36 UTC (rev 9240)
+++ django/trunk/tests/regressiontests/admin_views/tests.py 2008-10-21 
19:03:21 UTC (rev 9241)
@@ -12,7 +12,7 @@
 from models import Article, CustomArticle, Section, ModelWithStringPrimaryKey
 
 class AdminViewBasicTest(TestCase):
-fixtures = ['admin-views-users.xml']
+fixtures = ['admin-views-users.xml', 'admin-views-colors.xml']
 
 def setUp(self):
 self.client.login(username='super', password='secret')
@@ -147,6 +147,19 @@
 response.content.index('Middle content') < 
response.content.index('Newest content'),
 "Results of sorting on ModelAdmin method are out of order."
 )
+
+def testLimitedFilter(self):
+"""Ensure admin changelist filters do not contain objects excluded via 
limit_choices_to."""
+response = self.client.get('/test_admin/admin/admin_views/thing/')
+self.failUnlessEqual(response.status_code, 200)
+self.failUnless(
+'' in response.content, 
+"Expected filter not found in changelist view."
+)
+self.failIf(
+'Blue' in response.content,
+"Changelist filter not 

Re: [Django] #9335: TypedChoiceField, default empty value not unicode

[Django]

#9335: TypedChoiceField, default empty value not unicode
---+
  Reporter:  fas   | Owner:  fas

Status:  new   | Milestone:  post-1.0   

 Component:  Forms |   Version:  1.0

Resolution:|  Keywords:  TypedChoiceField, unicode, 
empty, data truncated for column
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  1  

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

  * needs_tests:  0 => 1
  * stage:  Ready for checkin => Accepted

Comment:

 This looks harmless, and maybe I'm a bit dim, but I'm missing how
 returning `''` instead of `u''` can lead to 'Data truncated for column'
 errors.  A test that exhibits the problem -- failing before the change,
 passing after it -- would help clarify.  Even one-liner fixes deserve
 tests.  Also, you're really not supposed to triage your own patches into
 'ready for checkin' -- that's supposed to indicate another set of eyes has
 looked it over and agrees with the problem & fix.

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9413: naming a template tag library the same as an app causes import problems

[Django]

#9413: naming a template tag library the same as an app causes import problems
+---
  Reporter:  akaihola   | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by akaihola):

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

Comment:

 I had this problem with the photologue re-usable app and had to get this
 working. So here's a dirty work-around.

 Say you have the following file structure under a directory which is in
 {{{PYTHONPATH}}}:
 {{{
 photologue/
   __init__.py
   models.py
   templatetags/
 __init__.py
 photologue.py
 myapp/
   __init__.py
   models.py
   templatetags/
 __init__.py
 myapp_tags.py
 }}}

 In {{{myapp_tags.py}}}, this is going to fail:
 {{{
 from photologue.models import Photo
 }}}

 Instead, you can
 {{{
 photologue_models = __import__('photologue.models', {}, {}, [''])
 Photo = photologue_models.Photo
 }}}

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9413: naming a template tag library the same as an app causes import problems

[Django]

#9413: naming a template tag library the same as an app causes import problems
---+
 Reporter:  akaihola   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The Django documentation warns about name clashes between custom tag
 libraries. However, there's no mention about the following problem:

 If you have the same name for an app and a tag library, you can't import
 the app from any other tag libraries. Python first looks up the name among
 all tag libraries, finds the module there and tries to import that.

 This behavior and the incompleteness of the documentation was confirmed by
 Eric Holscher and lericson on #django-dev a few minutes ago.

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9412: typo in custom model fields docs

[Django]

#9412: typo in custom model fields docs
---+
 Reporter:  carljm |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 There is a misplaced backtick on line 440 of docs/howto/custom-model-
 fields.txt that causes a class reference to fail.

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9411: Test added in [9081] fails on MySQL

[Django]

#9411: Test added in [9081] fails on MySQL
---+
 Reporter:  kmtracey   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 [9081] added:

 {{{
 Make sure bump_prefix() (an internal Query method) doesn't (re-)break.
 >>> query = Tag.objects.values_list('id').order_by().query
 >>> query.bump_prefix()
 >>> print query.as_sql()[0]
 SELECT U0."id" FROM "queries_tag" U0
 }}}

 to regressionstest/queries/models.py but this fails on MySQL due to
 quoting differences:

 {{{
 ==
 FAIL: Doctest: regressiontests.queries.models.__test__.API_TESTS
 --
 Traceback (most recent call last):
   File "/home/kmt/django/trunk/django/test/_doctest.py", line 2180, in
 runTest
 raise self.failureException(self.format_failure(new.getvalue()))
 AssertionError: Failed doctest test for
 regressiontests.queries.models.__test__.API_TESTS
   File "/home/kmt/django/trunk/tests/regressiontests/queries/models.py",
 line unknown line number, in API_TESTS

 --
 File "/home/kmt/django/trunk/tests/regressiontests/queries/models.py",
 line ?, in regressiontests.queries.models.__test__.API_TESTS
 Failed example:
 print query.as_sql()[0]
 Expected:
 SELECT U0."id" FROM "queries_tag" U0
 Got:
 SELECT U0.`id` FROM `queries_tag` U0


 --
 Ran 1 test in 1.251s

 FAILED (failures=1)
 }}}

 Not sure how to fix it since I'm not sure how much of that output is
 significant.  Is it sufficient that no exception was raised (seemed to be
 what happened before the fix)?  Or do we have a general way of dealing
 with quoting differences in backends (like file path differences)?

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #6148: Add generic support for database schemas

[Django]

#6148: Add generic support for database schemas
---+
  Reporter:  ikelly| Owner: 

Status:  new   | Milestone: 

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

Resolution:|  Keywords:  oracle 
postgresql mysql schemas
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  1 |  
---+
Changes (by kmtracey):

  * stage:  Unreviewed => Accepted

Comment:

 Restoring triage stage to Accepted.

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9240 - in django/branches/releases/1.0.X: . django/forms tests/modeltests/model_forms

[noreply]

Author: kmtracey
Date: 2008-10-21 09:07:36 -0500 (Tue, 21 Oct 2008)
New Revision: 9240

Modified:
   django/branches/releases/1.0.X/
   django/branches/releases/1.0.X/django/forms/models.py
   django/branches/releases/1.0.X/tests/modeltests/model_forms/models.py
Log:
[1.0.X] Fixed #9039 -- Don't perform unique checks on NULL values, since NULL 
!= NULL in SQL.

Backport of [9239] from trunk.



Property changes on: django/branches/releases/1.0.X
___
Name: svnmerge-integrated
   - 
/django/trunk:1-9097,9099-9102,9104-9109,9111,9113-9144,9146-9151,9153-9156,9158-9159,9161-9187,9189-9233,9235
   + 
/django/trunk:1-9097,9099-9102,9104-9109,9111,9113-9144,9146-9151,9153-9156,9158-9159,9161-9187,9189-9239

Modified: django/branches/releases/1.0.X/django/forms/models.py
===
--- django/branches/releases/1.0.X/django/forms/models.py   2008-10-21 
14:04:24 UTC (rev 9239)
+++ django/branches/releases/1.0.X/django/forms/models.py   2008-10-21 
14:07:36 UTC (rev 9240)
@@ -216,34 +216,31 @@
 def validate_unique(self):
 from django.db.models.fields import FieldDoesNotExist
 
-# Gather a list of checks to perform. Since this is a ModelForm, some
-# fields may have been excluded; we can't perform a unique check on a
-# form that is missing fields involved in that check.
+# Gather a list of checks to perform. We only perform unique checks 
+# for fields present and not None in cleaned_data.  Since this is a 
+# ModelForm, some fields may have been excluded; we can't perform a 
unique 
+# check on a form that is missing fields involved in that check.  It 
also does
+# not make sense to check data that didn't validate, and since NULL 
does not 
+# equal NULL in SQL we should not do any unique checking for NULL 
values.
 unique_checks = []
 for check in self.instance._meta.unique_together[:]:
-fields_on_form = [field for field in check if field in self.fields]
+fields_on_form = [field for field in check if field in 
self.cleaned_data and not self.cleaned_data[field] is None]
 if len(fields_on_form) == len(check):
 unique_checks.append(check)
 
 form_errors = []
 
 # Gather a list of checks for fields declared as unique and add them to
-# the list of checks. Again, skip fields not on the form.
+# the list of checks. Again, skip empty fields and any that did not 
validate.
 for name, field in self.fields.items():
 try:
 f = self.instance._meta.get_field_by_name(name)[0]
 except FieldDoesNotExist:
 # This is an extra field that's not on the ModelForm, ignore it
 continue
-# MySQL can't handle ... WHERE pk IS NULL, so make sure we
-# don't generate queries of that form.
-is_null_pk = f.primary_key and self.cleaned_data[name] is None
-if name in self.cleaned_data and f.unique and not is_null_pk:
+if f.unique and name in self.cleaned_data and not 
self.cleaned_data[name] is None:
 unique_checks.append((name,))
 
-# Don't run unique checks on fields that already have an error.
-unique_checks = [check for check in unique_checks if not [x in 
self._errors for x in check if x in self._errors]]
-
 bad_fields = set()
 for unique_check in unique_checks:
 # Try to look up an existing object with the same values as this

Modified: django/branches/releases/1.0.X/tests/modeltests/model_forms/models.py
===
--- django/branches/releases/1.0.X/tests/modeltests/model_forms/models.py   
2008-10-21 14:04:24 UTC (rev 9239)
+++ django/branches/releases/1.0.X/tests/modeltests/model_forms/models.py   
2008-10-21 14:07:36 UTC (rev 9240)
@@ -145,7 +145,15 @@
 
def __unicode__(self):
   return self.name
-  
+
+class Book(models.Model):
+title = models.CharField(max_length=40)
+author = models.ForeignKey(Writer, blank=True, null=True)
+special_id = models.IntegerField(blank=True, null=True, unique=True)
+
+class Meta:
+unique_together = ('title', 'author')
+
 __test__ = {'API_TESTS': """
 >>> from django import forms
 >>> from django.forms.models import ModelForm, model_to_dict
@@ -1201,6 +1209,32 @@
 >>> form.is_valid()
 True
 
+# Unique & unique together with null values
+>>> class BookForm(ModelForm): 
+... class Meta: 
+...model = Book
+>>> w = Writer.objects.get(name='Mike Royko')
+>>> form = BookForm({'title': 'I May Be Wrong But I Doubt It', 'author' : 
w.pk})
+>>> form.is_valid()
+True
+>>> form.save()
+
+>>> form = BookForm({'title': 'I May Be Wrong But I Doubt It', 'author' : 
w.pk})
+>>> form.is_valid()
+False

[Changeset] r9239 - in django/trunk: django/forms tests/modeltests/model_forms

[noreply]

Author: kmtracey
Date: 2008-10-21 09:04:24 -0500 (Tue, 21 Oct 2008)
New Revision: 9239

Modified:
   django/trunk/django/forms/models.py
   django/trunk/tests/modeltests/model_forms/models.py
Log:
Fixed #9039 -- Don't perform unique checks on NULL values, since NULL != NULL 
in SQL.


Modified: django/trunk/django/forms/models.py
===
--- django/trunk/django/forms/models.py 2008-10-21 04:45:55 UTC (rev 9238)
+++ django/trunk/django/forms/models.py 2008-10-21 14:04:24 UTC (rev 9239)
@@ -216,34 +216,31 @@
 def validate_unique(self):
 from django.db.models.fields import FieldDoesNotExist
 
-# Gather a list of checks to perform. Since this is a ModelForm, some
-# fields may have been excluded; we can't perform a unique check on a
-# form that is missing fields involved in that check.
+# Gather a list of checks to perform. We only perform unique checks 
+# for fields present and not None in cleaned_data.  Since this is a 
+# ModelForm, some fields may have been excluded; we can't perform a 
unique 
+# check on a form that is missing fields involved in that check.  It 
also does
+# not make sense to check data that didn't validate, and since NULL 
does not 
+# equal NULL in SQL we should not do any unique checking for NULL 
values.
 unique_checks = []
 for check in self.instance._meta.unique_together[:]:
-fields_on_form = [field for field in check if field in self.fields]
+fields_on_form = [field for field in check if field in 
self.cleaned_data and not self.cleaned_data[field] is None]
 if len(fields_on_form) == len(check):
 unique_checks.append(check)
 
 form_errors = []
 
 # Gather a list of checks for fields declared as unique and add them to
-# the list of checks. Again, skip fields not on the form.
+# the list of checks. Again, skip empty fields and any that did not 
validate.
 for name, field in self.fields.items():
 try:
 f = self.instance._meta.get_field_by_name(name)[0]
 except FieldDoesNotExist:
 # This is an extra field that's not on the ModelForm, ignore it
 continue
-# MySQL can't handle ... WHERE pk IS NULL, so make sure we
-# don't generate queries of that form.
-is_null_pk = f.primary_key and self.cleaned_data[name] is None
-if name in self.cleaned_data and f.unique and not is_null_pk:
+if f.unique and name in self.cleaned_data and not 
self.cleaned_data[name] is None:
 unique_checks.append((name,))
 
-# Don't run unique checks on fields that already have an error.
-unique_checks = [check for check in unique_checks if not [x in 
self._errors for x in check if x in self._errors]]
-
 bad_fields = set()
 for unique_check in unique_checks:
 # Try to look up an existing object with the same values as this

Modified: django/trunk/tests/modeltests/model_forms/models.py
===
--- django/trunk/tests/modeltests/model_forms/models.py 2008-10-21 04:45:55 UTC 
(rev 9238)
+++ django/trunk/tests/modeltests/model_forms/models.py 2008-10-21 14:04:24 UTC 
(rev 9239)
@@ -145,7 +145,15 @@
 
def __unicode__(self):
   return self.name
-  
+
+class Book(models.Model):
+title = models.CharField(max_length=40)
+author = models.ForeignKey(Writer, blank=True, null=True)
+special_id = models.IntegerField(blank=True, null=True, unique=True)
+
+class Meta:
+unique_together = ('title', 'author')
+
 __test__ = {'API_TESTS': """
 >>> from django import forms
 >>> from django.forms.models import ModelForm, model_to_dict
@@ -1201,6 +1209,32 @@
 >>> form.is_valid()
 True
 
+# Unique & unique together with null values
+>>> class BookForm(ModelForm): 
+... class Meta: 
+...model = Book
+>>> w = Writer.objects.get(name='Mike Royko')
+>>> form = BookForm({'title': 'I May Be Wrong But I Doubt It', 'author' : 
w.pk})
+>>> form.is_valid()
+True
+>>> form.save()
+
+>>> form = BookForm({'title': 'I May Be Wrong But I Doubt It', 'author' : 
w.pk})
+>>> form.is_valid()
+False
+>>> form._errors
+{'__all__': [u'Book with this Title and Author already exists.']}
+>>> form = BookForm({'title': 'I May Be Wrong But I Doubt It'})
+>>> form.is_valid()
+True
+>>> form.save()
+
+>>> form = BookForm({'title': 'I May Be Wrong But I Doubt It'})
+>>> form.is_valid()
+True
+>>> form.save()
+
+
 # Choices on CharField and IntegerField
 >>> class ArticleForm(ModelForm):
 ... class Meta:


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to 

Re: [Django] #9410: global_settings pt LANGUAGE

[Django]

#9410: global_settings pt LANGUAGE
+---
  Reporter:  kimus  | Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by kimus):

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

Comment:

 i just notice that all locales are using the wrong 'Portugese' id :-S,
 this is not so bad because is just a translated id string but when using
 the right phrase in our projects then will not be localized!

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8165: When using can_order=True on formset, ordered_forms is not avaible when formset.is_valid() is false

[Django]

#8165: When using can_order=True on formset, ordered_forms is not avaible when
formset.is_valid() is false
---+
  Reporter:  James Chua <[EMAIL PROTECTED]>  | Owner:  brosner 
Status:  reopened  | Milestone:  
post-1.0
 Component:  Forms |   Version:  SVN
 
Resolution:|  Keywords:  
formsets
 Stage:  Accepted  | Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by patrickk):

 I absolutely agree with james_027. why should ordered_forms only be
 available when is_valid() is true. it may be intentional to mirror
 cleaned_data, but that doesn´t mean it´s a good idea.

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9410: global_settings pt LANGUAGE

[Django]

#9410: global_settings pt LANGUAGE
---+
 Reporter:  kimus  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 has: ('pt', gettext_noop('Portugese')),

 should be: ('pt', gettext_noop('Portuguese')),

 in the 1.0, and SVN

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9409: "OperationalError: database is locked" with Python 2.6 multiprocessing and SQLite backend

[Django]

#9409: "OperationalError: database is locked" with Python 2.6 multiprocessing 
and
SQLite backend
---+
  Reporter:  mrts  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by mrts):

 This seems to be SQLite-specific, e.g. MySQL backend is not affected. If
 it's hard to fix (e.g. extra heavy-weight locking machinery), it should be
 probably ''wontfix''ed.

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #5685: [patch] Add ability to perform pre-runtime setup before executing code

[Django]

#5685: [patch] Add ability to perform pre-runtime setup before executing code
-+--
  Reporter:  __hawkeye__ | Owner:  
Status:  new | Milestone:  post-1.0
 Component:  Core framework  |   Version:  SVN 
Resolution:  |  Keywords:  
 Stage:  Accepted| Has_patch:  0   
Needs_docs:  1   |   Needs_tests:  1   
Needs_better_patch:  0   |  
-+--
Changes (by guettli):

 * cc: [EMAIL PROTECTED] (added)

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9409: "OperationalError: database is locked" with Python 2.6 multiprocessing and SQLite backend

[Django]

#9409: "OperationalError: database is locked" with Python 2.6 multiprocessing 
and
SQLite backend
---+
  Reporter:  mrts  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

  * needs_better_patch:  => 0
  * summary:  OperationalError: database is locked with Python 2.6
  multiprocessing and SQLite backend =>
  "OperationalError: database is locked" with
  Python 2.6 multiprocessing and SQLite backend
  * needs_tests:  => 0
  * needs_docs:  => 0

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9409: OperationalError: database is locked with Python 2.6 multiprocessing and SQLite backend

[Django]

#9409: OperationalError: database is locked with Python 2.6 multiprocessing and
SQLite backend
--+-
 Reporter:  mrts  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Running the attached test cases in Ubuntu Hardy with Python 2.6, saving
 models to database fails with

 {{{
 Process ConcurrentAccess-79:
 Traceback (most recent call last):
   File "/usr/local/lib/python2.6/multiprocessing/process.py", line 231, in
 _bootstrap
 self.run()
   File "./db_locked_error.py", line 18, in run
 f.save()
   File "/usr/local/lib/python2.6/site-packages/Django-1.0_final-
 py2.6.egg/django/db/models/base.py", line 307, in save
 self.save_base(force_insert=force_insert, force_update=force_update)
   File "/usr/local/lib/python2.6/site-packages/Django-1.0_final-
 py2.6.egg/django/db/models/base.py", line 379, in save_base
 result = manager._insert(values, return_id=update_pk)
   File "/usr/local/lib/python2.6/site-packages/Django-1.0_final-
 py2.6.egg/django/db/models/manager.py", line 138, in _insert
 return insert_query(self.model, values, **kwargs)
   File "/usr/local/lib/python2.6/site-packages/Django-1.0_final-
 py2.6.egg/django/db/models/query.py", line 888, in insert_query
 return query.execute_sql(return_id)
   File "/usr/local/lib/python2.6/site-packages/Django-1.0_final-
 py2.6.egg/django/db/models/sql/subqueries.py", line 308, in execute_sql
 cursor = super(InsertQuery, self).execute_sql(None)
   File "/usr/local/lib/python2.6/site-packages/Django-1.0_final-
 py2.6.egg/django/db/models/sql/query.py", line 1700, in execute_sql
 cursor.execute(sql, params)
   File "/usr/local/lib/python2.6/site-packages/Django-1.0_final-
 py2.6.egg/django/db/backends/util.py", line 19, in execute
 return self.cursor.execute(sql, params)
   File "/usr/local/lib/python2.6/site-packages/Django-1.0_final-
 py2.6.egg/django/db/backends/sqlite3/base.py", line 167, in execute
 return Database.Cursor.execute(self, query, params)
 OperationalError: database is locked
 }}}

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9408: Oracle backend, error in Oracle's FormatStylePlaceholderCursor _format_params method

[Django]

#9408: Oracle backend, error in Oracle's FormatStylePlaceholderCursor
_format_params method
---+
  Reporter:  ramiro| Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.0
  
Resolution:|  Keywords:  oracle 
_format_params
 Stage:  Unreviewed| Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

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

Old description:

> This was been reported in passing in the #5543 attachment comment but it
> can ba fixed independently so I'm reporting it here.

New description:

 This was been reported in passing in the #5543 attachment comment but it
 can ba fixed independently so I'm reporting it here just inc ase it' a
 real problem.

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9408: Oracle backend, error in Oracle's FormatStylePlaceholderCursor _format_params method

[Django]

#9408: Oracle backend, error in Oracle's FormatStylePlaceholderCursor
_format_params method
--+-
 Reporter:  ramiro|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.0   
 Keywords:  oracle _format_params |   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 This was been reported in passing in the #5543 attachment comment but it
 can ba fixed independently so I'm reporting it here.

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9407: The testModerationQueueContents test case does not work on databases without a microsecond precision datetime data type

[Django]

#9407: The testModerationQueueContents test case does not work on databases
without a microsecond precision datetime data type
---+
  Reporter:  egenix_viktor | Owner:  nobody 

Status:  new   | Milestone: 

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

Resolution:|  Keywords:  MSSQL 
microsecond datetime ordering
 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

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

Comment:

 It is actually in
 `regressiontests/comment_tests/tests/moderation_view_tests'.

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9407: The testModerationQueueContents test case does not work on databases without a microsecond precision datetime data type

[Django]

#9407: The testModerationQueueContents test case does not work on databases
without a microsecond precision datetime data type
-+--
 Reporter:  egenix_viktor|   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Database layer (models, ORM) | Version:  1.0   
 Keywords:  MSSQL microsecond datetime ordering  |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 Database server: MS SQL Server 2005

 Unit test: `regressiontests/moderation_view_tests`

 Test case: `ModerationQueueTests.testModerationQueueContents`

 Statement: `self.assertEqual(list(response.context[0]["comments"]), [c1,
 c2])`

 The test fails due to wrong row order, since
 `list(response.context[0]["comments"])` gives `[c2, c1]` instead of `[c1,
 c2]`.

 The SQL query generated (split into multiple lines for readability):

 {{{
 SELECT TOP 2
 [django_comments].[id],
 [django_comments].[content_type_id],
 [django_comments].[object_pk],
 [django_comments].[site_id],
 [django_comments].[user_id],
 [django_comments].[user_name],
 [django_comments].[user_email],
 [django_comments].[user_url],
 [django_comments].[comment],
 [django_comments].[submit_date],
 [django_comments].[ip_address],
 [django_comments].[is_public],
 [django_comments].[is_removed]
 FROM [django_comments]
 WHERE ([django_comments].[is_public] = %s AND
[django_comments].[is_removed] = %s )
 ORDER BY [django_comments].[submit_date] ASC
 }}}

 Parameters:

 {{{
 (False, False)
 }}}

 Which will be translated to `(0, 0)`.

 The above test case depends on sorting the comments on their
 `submit_date`. Since MS SQL does not have a microsecond component in its
 `datetime` columns both comments are inserted with the same `submit_date`
 value with nearly 100% probability. It might cause a result set with
 unexpected record order, since the above query sorts the rows on a column
 containing identical values, therefore no sort order defined at all.

 So, this bug is due to the lack of microsecond precision of MS SQL
 Server's `datetime` data type. However, it works on SQLite, since SQLite
 can store the microseconds as well.

 The test case should be modified to insert the test data with different
 `submit_date` values or sort on the primary key as well as a secondary
 ordering.

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9406: Query.as_sql() generates invalid ORDER BY clause

[Django]

#9406: Query.as_sql() generates invalid ORDER BY clause
---+
  Reporter:  egenix_viktor | Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.0
  
Resolution:|  Keywords:  Query 
as_sql ORDER clause ordering duplicate wrong SQL generate generates
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by egenix_viktor):

  * keywords:  => Query as_sql ORDER clause ordering duplicate wrong SQL
   generate generates
  * needs_better_patch:  => 0
  * component:  Uncategorized => Database layer (models, ORM)
  * needs_tests:  => 0
  * needs_docs:  => 0

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9406: Query.as_sql() generates invalid ORDER BY clause

[Django]

#9406: Query.as_sql() generates invalid ORDER BY clause
---+
 Reporter:  egenix_viktor  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Backend: SQLite

 Test case: `regressiontests/model_inheritance_regress`

 Statement: `c1.get_next_by_pub_date()`

 The `Query.as_sql()` method in `django.db.models.sql.query` generates two
 ordering items for the same
 `"model_inheritance_regress_article"."pub_date"` field:

 (The generated query has been split into multiple lines for readability.)

 {{{
 SELECT
 "model_inheritance_regress_article"."id",
 "model_inheritance_regress_article"."headline",
 "model_inheritance_regress_article"."pub_date",
 "model_inheritance_regress_articlewithauthor"."article_ptr_id",
 "model_inheritance_regress_articlewithauthor"."author"
 FROM "model_inheritance_regress_articlewithauthor"
 INNER JOIN "model_inheritance_regress_article"
 ON ("model_inheritance_regress_articlewithauthor"."article_ptr_id" =
 "model_inheritance_regress_article"."id")
 WHERE (
 "model_inheritance_regress_article"."pub_date" > %s OR  (
 "model_inheritance_regress_articlewithauthor"."article_ptr_id" >
 %s AND
 "model_inheritance_regress_article"."pub_date" = %s ))
 ORDER BY
 "model_inheritance_regress_article"."pub_date" ASC,
 "model_inheritance_regress_article"."pub_date" DESC,
 "model_inheritance_regress_article"."headline" ASC
 LIMIT 1
 }}}

 Parameters:

 {{{
 (u'2005-08-01 03:00:00', 1, u'2005-08-01 03:00:00')
 }}}

 It works on SQLite for some reason, but such an `ORDER BY` clause causes
 an error message on many database servers, such as on MS SQL Server 2005
 (when used with another backend, certainly).

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #6148: Add generic support for database schemas

[Django]

#6148: Add generic support for database schemas
---+
  Reporter:  ikelly| Owner: 

Status:  new   | Milestone: 

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

Resolution:|  Keywords:  oracle 
postgresql mysql schemas
 Stage:  Unreviewed| Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  1 |  
---+
Changes (by crippledcanary):

  * owner:  crippledcanary =>
  * status:  assigned => new
  * stage:  Accepted => Unreviewed

Comment:

 I don't have time to fix this right now... Better someone else does it.

-- 
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-updates@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-updates?hl=en
-~--~~~~--~~--~--~---