Re: [Django] #14019: SQLInsertCompiler.as_sql() failure

[Django]

#14019: SQLInsertCompiler.as_sql() failure
---+
  Reporter:  mlavin| Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by mlavin):

 I don't have a simple example using the public API yet. The scenario that
 brought me to this issue was I have a set of unmanaged models (from a
 legacy database). An app was built to create these models but was
 violating a table constraint. When the insert failed the exception was
 caught and django-db-log tried to print out the failing SQL statement.
 Calling `Query.__str__` called `SQLInsertCompiler.as_sql` which failed
 because `return_id` was never set.

-- 
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] #14020: Make HttpResponse.get work like dict.get

[Django]

#14020: Make HttpResponse.get work like dict.get
---+
 Reporter:  schmichael |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 {{{
 #!python
 >>> from django import http
 >>> resp = http.HttpResponse()
 >>> resp['Connection'] = 'close'
 >>> resp.get('Connection')
 Traceback (most recent call last):
   File "", line 1, in 
 TypeError: get() takes exactly 3 arguments (2 given)
 }}}

 {{{
 #!html
 http://schmichael.com/files/orly.png"/>
 }}}

 {{{
 #!python
 >>> foo = {}
 >>> foo.get('Connection')
 >>>
 }}}

-- 
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] #14019: SQLInsertCompiler.as_sql() failure

[Django]

#14019: SQLInsertCompiler.as_sql() failure
---+
  Reporter:  mlavin| Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by Alex):

 The Query classes are an internal API, is there a way to reproduce this
 with the public API?

-- 
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] #13613: forms.URLField not default ModelForm URLField anymore

[Django]

#13613: forms.URLField not default ModelForm URLField anymore
-+--
  Reporter:  amadison| Owner:  nobody
Status:  new | Milestone:  1.3   
 Component:  Forms   |   Version:  1.2   
Resolution:  |  Keywords:  ModelForm URLField
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by Leo):

 +1 for a fix, ideally in a 1.2.x release.

 We're running into this bug as well since upgrading to 1.2.

-- 
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] #14019: SQLInsertCompiler.as_sql() failure

[Django]

#14019: SQLInsertCompiler.as_sql() failure
---+
  Reporter:  mlavin| Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by manfre):

 * cc: manfre (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-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] #14019: SQLInsertCompiler.as_sql() failure

[Django]

#14019: SQLInsertCompiler.as_sql() failure
---+
  Reporter:  mlavin| Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by mlavin):

  * needs_better_patch:  => 0
  * has_patch:  0 => 1
  * 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-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] #14019: SQLInsertCompiler.as_sql() failure

[Django]

#14019: SQLInsertCompiler.as_sql() failure
--+-
 Reporter:  mlavin|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I came across a problem with `SQLInsertCompiler.as_sql` function while
 trying to get a stacktrace printed on insert errors (using
 [http://github.com/dcramer/django-db-log django-db-log]). I found that the
 `as_sql` function has an implicit condition that `execute_sql` must be
 called first because `execute_sql` sets the `return_id` attribute. This
 simple sequence shows the issue using any core db-backend:

 {{{
 from django.contrib.auth.models import User
 from django.db import router
 from django.db.models.sql import InsertQuery

 db = router.db_for_write(User)
 query = InsertQuery(User)
 query.insert_values([(User._meta.fields[0], 1)], raw_values=False)
 print query.get_compiler(using=db).as_sql()
 }}}

 yields

 {{{
 AttributeError: 'SQLInsertCompiler' object has no attribute 'return_id'
 }}}

 I've attached a patch which checks for the existence of the `return_id`
 attribute and defaults to `False` if not found (as is the convention in
 `execute_sql`).

-- 
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] #11397: [New Feature In Admin] Added Edit-Icon in selection widget of ForeignKey and ManyToMany Fields(Relationship fields).

[Django]

#11397: [New Feature In Admin] Added Edit-Icon in selection widget of ForeignKey
and ManyToMany Fields(Relationship fields).
---+
  Reporter:  dharmesh  | Owner:  Dharmesh [Patel
  
Status:  new   | Milestone: 
  
 Component:  django.contrib.admin  |   Version:  1.1-beta-1 
  
Resolution:|  Keywords:  Edit Icon, edit 
selected item in selection widget
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by dharmesh):

 stage is just changed from 'unreviewed' to 'Accepted' by Alex only and
 then there is no feedback about 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-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] #11397: [New Feature In Admin] Added Edit-Icon in selection widget of ForeignKey and ManyToMany Fields(Relationship fields).

[Django]

#11397: [New Feature In Admin] Added Edit-Icon in selection widget of ForeignKey
and ManyToMany Fields(Relationship fields).
---+
  Reporter:  dharmesh  | Owner:  Dharmesh [Patel
  
Status:  new   | Milestone: 
  
 Component:  django.contrib.admin  |   Version:  1.1-beta-1 
  
Resolution:|  Keywords:  Edit Icon, edit 
selected item in selection widget
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by dharmesh):

 that feature I already give to add in 1.1 beta version, but till I can not
 get any feedback from django community :(

-- 
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] #11397: [New Feature In Admin] Added Edit-Icon in selection widget of ForeignKey and ManyToMany Fields(Relationship fields).

[Django]

#11397: [New Feature In Admin] Added Edit-Icon in selection widget of ForeignKey
and ManyToMany Fields(Relationship fields).
---+
  Reporter:  dharmesh  | Owner:  Dharmesh [Patel
  
Status:  new   | Milestone: 
  
 Component:  django.contrib.admin  |   Version:  1.1-beta-1 
  
Resolution:|  Keywords:  Edit Icon, edit 
selected item in selection widget
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by drdee):

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

Comment:

 What is the status of this ticket? Is this something for Django 1.3?

-- 
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] #14018: Introduce class_plural %-substitution placeholder for related_name of ForeignKey/ManyToManyField

[Django]

#14018: Introduce class_plural %-substitution placeholder for related_name of
ForeignKey/ManyToManyField
+
 Reporter:  puxlit  |   
Owner:  nobody
   Status:  new |   
Milestone:  1.3   
Component:  Database layer (models, ORM)|   
  Version:  SVN   
 Keywords:  related_name, ManyToManyField, ForeignKey, abstract base class  |   
Stage:  Unreviewed
Has_patch:  1   |  
+
 Django 1.2 [http://docs.djangoproject.com/en/dev/topics/db/models/#be-
 careful-with-related-name introduced] two %-substitution placeholders,
 `%(class)s` and `%(app_label)s`, to work around uniqueness issues when a
 custom `related_name` for a `ForeignKey` or `ManyToManyField` defined in
 an abstract base class is inherited by multiple child classes.

 Quoting from [http://docs.djangoproject.com/en/dev/topics/db/models/#many-
 to-many-relationships Django's models documentation], "''It's suggested
 ![...] that the name of a `ManyToManyField` ![...] be a plural describing
 the set of related model objects.''" Given the nature of a
 `ManyToManyField`, it may be preferable to reciprocate this pluralized
 field naming style through `related_name`. By introducing a third
 %-substitution placeholder, `%(class_plural)s`, this can be accomplished.

 Consider the following snippet:

 {{{
 #!python

 class Tag(models.Model):
 slug = models.SlugField(max_length=63, unique=True)

 class Post(models.Model):
 slug = models.SlugField(max_length=127, unique=True)
 tags = models.ManyToManyField(Tag, related_name='%(class_plural)s') #
 docs suggest related_name='%(app_label)s_%(class)s_related'

 class Meta:
 abstract = True

 class Entry(Post):
 title = models.CharField(max_length=255)
 content = models.TextField()

 class Meta:
 verbose_name_plural = 'entries'

 class Event(Post):
 summary = models.CharField(max_length=255)
 start_date = models.DateTimeField()
 }}}

 Arguably, `tag.entries` and `tag.events` are more semantic than either
 `tag.entry_set` and `tag.event_set` or `tag.appname_entry_related` and
 `tag.appname_event_related`.

 Ultimately, the introduction of a `%(class_plural)s` %-substitution
 placeholder provides greater flexibility when designing models with
 abstract base classes and ForeignKeys or ManyToManyFields.

-- 
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] #14017: Wrong comment in django.contrib.admin.options log_deletion

[Django]

#14017: Wrong comment in django.contrib.admin.options log_deletion
--+-
 Reporter:  akaariai  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Comment of django.contrib.admin.options log_deletion says:

 {{{
 Log that an object has been successfully deleted. Note that since the
 object is deleted, it might no longer be safe to call *any* methods
 on the object, hence this method getting object_repr.
 }}}

 However this function is called before the object is deleted (from
 admin.actions delete_selected() and admin.options delete_view().

 The changeset that changed the order of obj.delete() and log_deletion() is
 r10686 fixing the issue reported in #10889. The reason for the change is
 that log_deletion needs the pk of the object, but this is set to none when
 obj.delete() is called.

 The comment should probably mention that this function is called before
 deletion, as opposed to log_change and log_addition.

-- 
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] #11639: Can't remove prepopulated fields from fieldset in ModelAdmin

[Django]

#11639: Can't remove prepopulated fields from fieldset in ModelAdmin
---+
  Reporter:  leanmeandonothingmachine  | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by leanmeandonothingmachine):

  * version:  1.1 => 1.2
  * milestone:  => 1.3

Comment:

 Updated the patch again. If there is anything wrong with this that is
 holding it up please lmk, i'd be happy to improve 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-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] #14016: SQLite3 problem with date comparison

[Django]

#14016: SQLite3 problem with date comparison
+---
 Reporter:  anonymous   |  Status:  new
Milestone:  |   Component:  ORM aggregation
  Version:  1.2 |Keywords:  sqlite, date comparison
Stage:  Unreviewed  |   Has_patch:  0  
+---
 I've hit a bug using Django 1.2.1.

 I've a model with date types. Django generates a query like this that
 returns the correct results:

 SELECT xxx FROM "table" WHERE ("table"."pub_date" >= 2010-01-24 );

 If I switch to "lt" or "lte" it gives me nothing, because sqlite seems to
 want "'" around the date. You can see for yourself in the following test
 case run with SQLite 3.6.16 and 3.7.0.

 +++

 $ sqlite3 prova.db[[BR]]
 SQLite version 3.6.16[[BR]]
 Enter ".help" for instructions[[BR]]
 Enter SQL statements terminated with a ";"[[BR]]
 sqlite> create table foo( d date null);[[BR]]
 sqlite> insert into foo(d) values( '2009-09-09' );[[BR]]
 sqlite> select * from foo where (d >= 2007-01-01);[[BR]]
 2009-09-09[[BR]]
 sqlite> select * from foo where (d <= 2010-01-01);[[BR]]
 sqlite> select * from foo where (d <= '2010-01-01');[[BR]]
 2009-09-09[[BR]]
 sqlite> [[BR]]

 +++

 $ sqlite3 prova.db[[BR]]
 SQLite version 3.7.0[[BR]]
 Enter ".help" for instructions[[BR]]
 Enter SQL statements terminated with a ";"[[BR]]
 sqlite> create table foo( d date null);[[BR]]
 sqlite> insert into foo(d) values( '2009-09-09' );[[BR]]
 sqlite> select * from foo where (d >= 2007-01-01);[[BR]]
 2009-09-09[[BR]]
 sqlite> select * from foo where (d <= 2010-01-01);[[BR]]
 sqlite> select * from foo where (d <= '2010-01-01');[[BR]]
 2009-09-09[[BR]]
 sqlite> [[BR]]

-- 
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] #14012: Adding an User object in a popup fails

[Django]

#14012: Adding an User object in a popup fails
---+
  Reporter:  g...@lka.hu | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Ready for checkin | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by kmtracey):

 "a username" reads correctly to me, "an username" reads wrong. I don't
 think new/changed translatable strings generally prevent fixes from being
 applied to a maint. branch -- better to fix the bug and have an
 untranslated string than not fix the bug at all. And new translations can
 be provided for the branch

-- 
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] #14015: django.contrib.localflavor.it added italian phone number validation

[Django]

#14015: django.contrib.localflavor.it added italian phone number validation
---+
 Reporter:  VoodooChile 
   |   Owner:  nobody
   Status:  new 
   |   Milestone:
Component:  django.contrib.localflavor  
   | Version:  1.2   
 Keywords:  django.contrib.localflavor.it ITPhoneNumberField form phone number 
validation  |   Stage:  Unreviewed
Has_patch:  1   
   |  
---+
 Hi to all,
 I found myself in need of an Italian phone numbers validator, so I wrote
 it as a localflavor element, and now I'm sharing it with the community of
 Django.
 The validation process is quite simple but yet very functional. The
 (eventual) international prefix (both +39 or 0039) is stripped from the
 number entered (something like 0039 010 1234567 -> 010 1234567).
 The local prefix (in example 010, the prefix for Genoa) is checked against
 a list of valid prefixes (both fixed line or mobile), and if the number
 meet all the requirements (containing only number, having a prefix between
 2 and 4 digits, and a number itself between 5 and 8 digits...) is returned
 as a cleaned value.

 Hope of being of some Help,
 Greetings,
 Andrea

-- 
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.