Re: [Django] #17788: bulk_create() "too many SQL variables" error

2012-09-02 Thread Django
#17788: bulk_create() "too many SQL variables" error
-+-
 Reporter:  alpar|Owner:  akaariai
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 Worth a note in docs/releases/1.4.2.txt?

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #17485: Queries with both deferred fields and select_related defer field.name instead of field.attname

2012-09-02 Thread Django
#17485: Queries with both deferred fields and select_related defer field.name
instead of field.attname
-+-
 Reporter:  konk |Owner:  konk
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  defer|  Needs documentation:  0
  select_related |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by mrmachine):

 * cc: real.human@… (added)
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Looks like there's a bug in this commit that was not caught by the
 included tests. When I try to use `only()` and `select_related()` and pass
 the same fields to both, spanning multiple FKs I get an erroneous
 exception telling me that I can't use `select_related` for a deferred
 field. That's not what I'm doing. I'm using `select_related` for a field
 that is explicitly NOT deferred.

 I have written a patch with a new test, but I don't have a fix because I
 don't fully understand what the code in this commit is doing.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #13910: Add generator version of Template.render(Context)

2012-09-02 Thread Django
#13910: Add generator version of Template.render(Context)
-+
 Reporter:  rooney   |Owner:  nobody
 Type:  New feature  |   Status:  reopened
Component:  Template system  |  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by mindsocket):

 * cc: mindsocket (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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #7581: Middleware accessing HttpResponse.content breaks streaming HttpResponse objects.

2012-09-02 Thread Django
#7581: Middleware accessing HttpResponse.content breaks streaming HttpResponse
objects.
-+-
 Reporter:  mrmachine|Owner:  ccahoon
 Type:  New feature  |   Status:  new
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  stream HttpResponse  | Triage Stage:  Accepted
  Content-Length |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by mindsocket):

 * cc: mindsocket (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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #15361: Document performance considerations when using Queryset.get()

2012-09-02 Thread Django
#15361: Document performance considerations when using Queryset.get()
-+-
 Reporter:  mbertheau|Owner:  mmcnickle
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.2
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by timo):

 * cc: timograham@… (added)
 * needs_better_patch:  1 => 0


Comment:

 Cleaned up doc patch, relaxed tests per Aymeric's suggestion.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #17788: bulk_create() "too many SQL variables" error

2012-09-02 Thread Django
#17788: bulk_create() "too many SQL variables" error
-+-
 Reporter:  alpar|Owner:  akaariai
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Anssi Kääriäinen ):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [23268608512444de626e63dee1815fb5b5207a48]:
 {{{
 #!CommitTicketReference repository=""
 revision="23268608512444de626e63dee1815fb5b5207a48"
 [1.4.x] Fixed #17788 -- Added batch_size argument to qs.bulk_create()

 The qs.bulk_create() method did not work with large batches together
 with SQLite3. This commit adds a way to split the bulk into smaller
 batches. The default batch size is unlimited except for SQLite3 where
 the batch size is limited to 999 SQL parameters per batch.

 Thanks to everybody who participated in the discussions at Trac.

 Backpatch of 29132ebdef0e0b9c09e456b05f0e6a22f1106a4f from master (with
 documentation changes removed).
 }}}

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




[django/django] 232686: [1.4.x] Fixed #17788 -- Added batch_size argument ...

2012-09-02 Thread GitHub
  Branch: refs/heads/stable/1.4.x
  Home:   https://github.com/django/django
  Commit: 23268608512444de626e63dee1815fb5b5207a48
  
https://github.com/django/django/commit/23268608512444de626e63dee1815fb5b5207a48
  Author: Anssi Kääriäinen 
  Date:   2012-09-02 (Sun, 02 Sep 2012)

  Changed paths:
M django/db/backends/__init__.py
M django/db/backends/sqlite3/base.py
M django/db/models/query.py
M tests/regressiontests/bulk_create/models.py
M tests/regressiontests/bulk_create/tests.py
M tests/regressiontests/queries/tests.py

  Log Message:
  ---
  [1.4.x] Fixed #17788 -- Added batch_size argument to qs.bulk_create()

The qs.bulk_create() method did not work with large batches together
with SQLite3. This commit adds a way to split the bulk into smaller
batches. The default batch size is unlimited except for SQLite3 where
the batch size is limited to 999 SQL parameters per batch.

Thanks to everybody who participated in the discussions at Trac.

Backpatch of 29132ebdef0e0b9c09e456b05f0e6a22f1106a4f from master (with
documentation changes removed).



-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #18063: repr() should return only ascii, not unicode

2012-09-02 Thread Django
#18063: repr() should return only ascii, not unicode
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 Completely agree with Karen.

 However, now that we tend to generalize unicode literals, we should take
 care not to use repr in other constructed strings (as in #17566), unless
 we can easily obtain !UnicodeDecodeError. Python 3, here we come!

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




[Django] #18896: get_or_create breaks for ManyToMany

2012-09-02 Thread Django
#18896: get_or_create breaks for ManyToMany
--+
 Reporter:  mattlong  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Using get_or_create through a ManyToMany field results in an integrity
 error if the object being queried for already exists but is not yet
 associated with the parent object:

 {{{
 class Tag(models.Model):
 text = models.CharField(max_length=256, unique=True)

 class Thing(models.Model):
 name = models.CharField(max_length=256)
 tags = models.ManyToManyField(Tag)

 #create and save a Tag
 Tag.objects.create(text='foo')

 #create and save a Thing
 a_thing = Thing.objects.create(name='a')

 #get the previously created Tag and have it associated with a_thing
 a_thing.tags.get_or_create(text='foo') #should get

 Traceback (most recent call last):
   File "", line 1, in 
   File "/usr/local/lib/python2.7/dist-
 packages/django/db/models/fields/related.py", line 616, in get_or_create
 super(ManyRelatedManager, self.db_manager(db)).get_or_create(**kwargs)
   File "/usr/local/lib/python2.7/dist-
 packages/django/db/models/manager.py", line 134, in get_or_create
 return self.get_query_set().get_or_create(**kwargs)
   File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py",
 line 449, in get_or_create
 obj.save(force_insert=True, using=self.db)
   File "/usr/local/lib/python2.7/dist-packages/django/db/models/base.py",
 line 463, in save
 self.save_base(using=using, force_insert=force_insert,
 force_update=force_update)
   File "/usr/local/lib/python2.7/dist-packages/django/db/models/base.py",
 line 551, in save_base
 result = manager._insert([self], fields=fields, return_id=update_pk,
 using=using, raw=raw)
   File "/usr/local/lib/python2.7/dist-
 packages/django/db/models/manager.py", line 203, in _insert
 return insert_query(self.model, objs, fields, **kwargs)
   File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py",
 line 1576, in insert_query
 return query.get_compiler(using=using).execute_sql(return_id)
   File "/usr/local/lib/python2.7/dist-
 packages/django/db/models/sql/compiler.py", line 910, in execute_sql
 cursor.execute(sql, params)
   File "/usr/local/lib/python2.7/dist-
 packages/django/db/backends/util.py", line 40, in execute
 return self.cursor.execute(sql, params)
   File "/usr/local/lib/python2.7/dist-
 packages/django/db/backends/sqlite3/base.py", line 337, in execute
 return Database.Cursor.execute(self, query, params)
 IntegrityError: column text is not unique
 }}}

 To summarize, if a Tag with text 'foo' exists but is not yet associated
 with a given Thing instance, using .tags.get_or_create(text='foo') raises
 an IntegrityError since it tries to re-create the same Tag.

 I'm not familiar with the Django ORM source code, but I've traced the
 issue to ManyRelatedManager's get_query_set method always including its
 core_filters. This results in the "get" portion of get_or_create to only
 return a hit if the Tag exists and is already associated to the calling
 Thing instance. Given the nature of a many-to-many relationship, it should
 not be a requirement that a Tag already be linked to the calling Thing for
 get_or_create to find it; it should be enough that the Tag simply exists.
 In this case, I would expect .tags.get_or_create(...) to just add/save the
 association between Thing and Tag and return the existing Tag.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #18063: repr() should return only ascii, not unicode

2012-09-02 Thread Django
#18063: repr() should return only ascii, not unicode
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by kmtracey):

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


Comment:

 Django code that generates an exception when handed a bytestring which
 contains non-ASCII characters is broken. '''That''' is the code that
 should be fixed. I strongly believe changing Model `__repr__` to avoid
 putting non-ASCII characters in it is the wrong approach. It is
 sidestepping a problem rather than fixing the source (or sources) of the
 problem.

 Bytestrings are ambiguous, yes. You need to rely on some other information
 to know how to properly decode bytestrings. However, in Python 2
 `__repr__` must return a bytestring, therefore Django must encode to
 something. The overall approach taken by Django, consistently, when
 unicode support was added, was to "assume utf-8" wherever a bytestring has
 to be decoded/encoded and the "correct" encoding is unknown. Returning a
 utf-8 encoded bytestring from `__repr__` is consistent with this overall
 approach. I don't believe it should be changed.

 I'm closing this wontfix. If you can lay out a case (or cases) where non-
 ASCII data in `__repr__` leads to exceptions caused by Django code, then
 we should fix those issues. But I don't believe the fixes will require
 changing the behavior of `__repr__`, and the original description and
 discussion so far here has focused solely on `__repr__`, which is the
 wrong place to look. Therefore please open a new ticket (or tickets) to
 address issues found where Django code cannot correctly handle non-ASCII
 data in `__repr__`.

-- 
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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.