71 rows where "changetime" is on date 2013-02-28

View and edit SQL

Suggested facets: changetime, stage, component, type, severity, version, owner, easy, has_patch, needs_better_patch, needs_tests, created (date), last_pulled_from_trac (date)

changetime (date)

  • 2013-02-28 · 71
id ▼ created changetime last_pulled_from_trac stage status component type severity version resolution summary description owner reporter keywords easy has_patch needs_better_patch needs_tests needs_docs ui_ux
5241 2007-08-24 09:48:49 2013-02-28 13:21:56 2019-06-24 01:11:02.214189 Accepted closed HTTP handling Bug Normal master fixed Response middleware runs too early for streaming responses In order to output very large HTML files or do progresive rendering I let a view return an iterator. The actual HTML file is generated at the last step os request processing. It works fine as long as I don't use gettext to translate any variable/string/template/... during generation. If I do, I always get the default translation. I hope the following code snippet will clarify what I mean: {{{ def test(request): def f(): print dict(request.session) yield "<html><body>\n" for lang in ('es', 'en'): yield '<a href="/i18n/setlang/?language=%(lang)s">%(lang)s</a><br>'%locals() for i in range(10): yield (_('Current time:')+' %s<br>\n')%datetime.datetime.now() time.sleep(1) yield "Done\n</body></html>\n" return HttpResponse(f()) }}} In this case 'Current time:' is never translated (it is easy to fix in this case but not in others). I found the problem and the patch working with Django 0.96 but I believe it also applies to the development version. aaugustin bittor internationalization, progresive rendering 0 0 0 0 0 0
5617 2007-09-26 22:43:00 2013-02-28 10:15:36 2019-06-24 01:15:21.024342 Accepted closed Database layer (models, ORM) New feature Release blocker master wontfix Default server_error view should render with RequestContext Currently, the default server_error view in django.views.defaults renders using the following code: {{{ return http.HttpResponseServerError(t.render(Context({}))) }}} However, this prevents the context processors specified in SETTINGS.TEMPLATE_CONTEXT_PROCESSORS from being loaded. For example, if a base.html might include branding that includes the current date and time (which is passed in through a custom context processor). Currently, if we try to extend base.html in the 500.html template, we get an error because the context variable for the date and time isn't loaded. The best solution seems to be similar to the way the page_not_found view renders: {{{ return http.HttpResponseServerError(t.render(RequestContext(request))) }}} Although the page_not_found view also passes in a request_path variable to RequestContext, I'm not sure if this is necessary. nobody Nick Fishman <kwlogical@bellsouth.net> server_error, RequestContext, error, templates 0 1 0 0 0 0
9796 2008-12-10 22:34:39 2013-02-28 10:15:36 2019-06-24 02:01:29.585082 Unreviewed closed Database layer (models, ORM)     1.0 fixed Aggregate classes unnescarily use instance attributes. They can instead use class attributes this is filed against the external aggregates branch   Alex   0 0 0 0 0 0
9797 2008-12-10 22:38:31 2013-02-28 10:15:36 2019-06-24 02:01:30.189831 Unreviewed closed Database layer (models, ORM)     1.0 fixed .count() should use aggregates internally count() should use the aggregate facilites internally in order to not duplicate logic. this is filed against the external aggregates branch   Alex   0 0 0 0 0 0
9834 2008-12-13 17:35:01 2013-02-28 10:15:36 2019-06-24 02:01:53.977379 Unreviewed closed Database layer (models, ORM)     1.0 fixed Aggregation classes can use class attributes for their type as well This is another place where class attrs can be used in place of instance ones. This makes the code a bit more readable, and probably slightly more performant as well. This is being filed against the external aggregation branch.   Alex   0 1 0 0 0 0
9845 2008-12-14 09:48:49 2013-02-28 10:15:36 2019-06-24 02:02:01.084514 Unreviewed closed Database layer (models, ORM)     1.0 fixed Aggregate regression tests fail against SQLite 3.5.9 The aggregation regress tests are known to pass against 3.4.0, but fail against 3.5.9. The output is the following: http://dpaste.com/hold/98963/ . I haven't been able to identify the cause yet. This is being filed against the external aggregation branch.   Alex   0 0 0 0 0 0
9870 2008-12-16 20:49:07 2013-02-28 10:15:36 2019-06-24 02:02:17.435389 Unreviewed closed Database layer (models, ORM)     1.0 fixed When querying aross a many to many field if the target is the primary key only join to the intermediary table If we are querying across a many to many field and we only want to access the primary key of the related data we can reduce our joins by only going to the intermediary table. This is being filed against the external aggregation branch.   Alex   0 1 0 0 0 0
10033 2009-01-15 14:24:05 2013-02-28 10:15:36 2019-06-24 02:04:03.414499 Unreviewed closed Database layer (models, ORM)     1.0 fixed Oracle test suite failures after aggregation checkin Trying to run the full test suite with the Oracle backend after updating to r9745 I'm seeing some errors. I was actually trying to run it with the transaction speedups from #8138, but backed off to bare trunk and individual tests when I started seeing unexpected errors. (The full suite takes about nine hours to run on this machine without #8138, so in testing aggregates on Oracle previously I limited the tests to the newly-added aggregation tests.) Anyway, the first test that fails is basic: {{{ D:\u\kmt\django\trunk>svn info Path: . URL: http://code.djangoproject.com/svn/django/trunk Repository Root: http://code.djangoproject.com/svn Repository UUID: bcc190cf-cafb-0310-a4f2-bffc1f526a37 Revision: 9745 Node Kind: directory Schedule: normal Last Changed Author: russellm Last Changed Rev: 9745 Last Changed Date: 2009-01-15 07:44:45 -0500 (Thu, 15 Jan 2009) D:\u\kmt\django\trunk>svn diff D:\u\kmt\django\trunk>echo %pythonpath% d:\u\kmt\django\trunk D:\u\kmt\django\trunk>cd tests D:\u\kmt\django\trunk\tests>\bin\Python2.5.2\python.exe runtests.py --settings=oracle --verbosity=1 basic Importing model basic Creating test database... Creating test database... Creating test user... Creating table django_content_type Creating table auth_permission Creating table auth_group Creating table auth_user Creating table auth_message Creating table django_site Creating table django_flatpage Creating table django_redirect Creating table django_session Creating table django_comments Creating table django_comment_flags Creating table django_admin_log Creating table basic_article Installing index for auth.Permission model Installing index for auth.Message model Installing index for flatpages.FlatPage model Installing index for redirects.Redirect model Installing index for comments.Comment model Installing index for comments.CommentFlag model Installing index for admin.LogEntry model F ====================================================================== FAIL: Doctest: modelte…   kmtracey oracle 0 1 0 0 0 0
10064 2009-01-18 21:57:05 2013-02-28 10:15:36 2019-06-24 02:04:23.404893 Unreviewed closed Database layer (models, ORM)     master fixed error: annotate doesn't support select_related models.py:[[BR]] {{{ class Account(models.Model): accountname = models.CharField(max_length=20) account_creator = models.ForeignKey(User) description = models.TextField(_('description'), blank=True) def __unicode__(self): return self.account class Category(models.Model): category_name = models.CharField(max_length=50) category_creator = models.ForeignKey(User) description = models.TextField(_('description'), blank=True) def __unicode__(self): return self.category class Transaction(models.Model): category = models.ForeignKey(Category) account_from = models.ForeignKey(Account, related_name='account_from') account_to = models.ForeignKey(Account, related_name='account_to') creator = models.ForeignKey(User) label = models.CharField(_('label'), max_length=30) description = models.TextField(_('description'), blank=True) ammount = models.DecimalField(_('amount'),max_digits=8, decimal_places=2) created_at = models.DateTimeField(_('created at'), default=datetime.now) updated_at = models.DateTimeField(_('updated at')) def __unicode__(self): return self.label }}} shell:[[BR]] {{{ >>> transactions=Transaction.objects.select_related('category','account_from','account_to').annotate(Sum('amount')).order_by('category','updated_at') >>> print transactions Traceback (most recent call last): File "<console>", line 1, in <module> File "C:\Python25\lib\site-packages\django\db\models\query.py", line 239, in __getitem__ return list(qs)[0] File "C:\Python25\lib\site-packages\django\db\models\query.py", line 163, in __len__ self._result_cache.extend(list(self._iter)) File "C:\Python25\lib\site-packages\django\db\models\query.py", line 294, in iterator setattr(obj, aggregate, row[i+aggregate_start]) IndexError: tuple index out of range }}}   olivius annotate 0 0 0 0 0 0
10100 2009-01-22 18:04:04 2013-02-28 10:15:36 2019-06-24 02:04:47.274072 Unreviewed closed Database layer (models, ORM)     master fixed "exclude" by annotation works like "filter" "Exclude" by annotation does not negate lookup parameters: {{{ >>> [g.num for g in Group.objects.annotate(num=Count('sites')).exclude(num=73)] [73] >>> [g.num for g in Group.objects.annotate(num=Count('sites')).filter(num=73)] [73] >>> e = Group.objects.annotate(num=Count('sites')).exclude(num=73).query.as_sql() >>> f = Group.objects.annotate(num=Count('sites')).filter(num=73).query.as_sql() >>> e == f True >>> Group.objects.annotate(num=Count('sites')).exclude(num=73).query.as_sql() (u'SELECT (...), COUNT(`sites`.`id`) AS `num` FROM `site_groups` LEFT OUTER JOIN `sites` ON (`site_groups`.`id` = `sites`.`group_id`) GROUP BY site_groups.id HAVING COUNT(`urls`.`id`) = %s ORDER BY NULL', (73,)) }}}   Anossov   0 0 0 0 0 0
10132 2009-01-27 07:15:22 2013-02-28 10:15:36 2019-06-24 02:05:08.025688 Unreviewed closed Database layer (models, ORM)     master fixed Aggregations add extra values to ValuesQuerySets From http://groups.google.com/group/django-users/browse_frm/thread/15b3c24dddd2a2d5/2214eba4328126ca {{{ #!python Item.objects.extra(select={"note_alias": "note"}).values("note_alias").annotate(Count("id")).order_by('note_id') }}} generates: {{{ #!sql SELECT (note_id) AS "note_alias", U0."id", COUNT("queries_item"."id") AS "id__count" FROM "queries_item" U0 GROUP BY "queries_item"."id", "queries_item"."name", "queries_item"."created", "queries_item"."modified", "queries_item"."creator_id", "queries_item"."note_id" }}} but should (possibly) generate: {{{ #!sql SELECT (note_id) AS "note_alias", COUNT("queries_item"."id") AS "id__count" FROM queries_item GROUP BY note_alias ORDER BY note_id }}}   Glenn   0 0 0 0 0 0
10142 2009-01-29 00:51:21 2013-02-28 10:15:36 2019-06-24 02:05:14.489311 Accepted closed Database layer (models, ORM)     master fixed Doctests failing on aggregation I'm getting a failure on running the test suite. I looked for an existing ticket with this problem, but didn't see one; sorry if I missed it. {{{ Environment =========== This is a checkout of SVN rev 9791. OS: Ubuntu 2.6.15-53-386 #1 PREEMPT Mon Nov 24 17:50:35 UTC 2008 i686 GNU/Linux Python: Python 2.4.3 (#2, Jul 31 2008, 21:56:52) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Database: postgresql (in settings.py), PostgreSQL 8.2 on Windows }}} {{{ Test Output =========== FAIL: Doctest: regressiontests.aggregation_regress.models.__test__.API_TESTS ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/django/test/_doctest.py", line 2180, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for regressiontests.aggregation_regress.models.__test__.API_TESTS File "/home/vinay/projects/django/upstream/tests/regressiontests/aggregation_regress/models.py", line unknown line number, in API_TESTS ---------------------------------------------------------------------- File "/home/vinay/projects/django/upstream/tests/regressiontests/aggregation_regress/models.py", line ?, in regressiontests.aggregation_regress.models.__test__.API_TESTS Failed example: Book.objects.aggregate(StdDev('pages')) Expected: {'pages__stddev': 311.46...} Got: {'pages__stddev': 341.19344464199003} ---------------------------------------------------------------------- File "/home/vinay/projects/django/upstream/tests/regressiontests/aggregation_regress/models.py", line ?, in regressiontests.aggregation_regress.models.__test__.API_TESTS Failed example: Book.objects.aggregate(StdDev('price')) Expected: {'price__stddev': 24.16...} Got: {'price__stddev': 26.467595848508797} ---------------------------------------------------------------------- File "/home/vinay/projects/django/upstream/tests/regressiontests/aggregation_regress/models.py"…   Vinay Sajip <vinay_sajip@yahoo.co.uk> doctest failure 0 0 0 0 0 0
10199 2009-02-06 05:21:21 2013-02-28 10:15:36 2019-06-24 02:05:51.723505 Accepted closed Database layer (models, ORM)     master fixed aggregate method on queryset shouldn't alter the state of the queryset basically it should clone the query so as not to affect the queryset for future usage, I'll post a testcase shortly. Alex Alex   0 1 0 0 0 0
10248 2009-02-12 21:49:38 2013-02-28 10:15:36 2019-06-24 02:06:23.493344 Accepted closed Database layer (models, ORM)     master fixed Calling .dates on a annotated queryset gives wrong sql Example models {{{ #!python class Photo(models.Model): title = models.CharField(max_length=30) class Gallery(models.Model): title = models.CharField(max_length=30) photos = models.ManyToManyField(Photo) date_published = models.DateField() }}} Query: {{{ #!python from django.db import connection from django.db.models import Count Gallery.objects.dates('date_published', 'year') print connection.queries[-1] Gallery.objects.annotate(photo_count=Count('photos__id')).dates('date_published', 'year') print connection.queries[-1] }}}   oyvind annotate dates queryset 0 1 0 0 0 0
10250 2009-02-12 22:32:38 2013-02-28 10:15:36 2019-06-24 02:06:24.825754 Accepted closed Database layer (models, ORM)     1.0 fixed MySQL quoting not happening for aggregation group by? Adding this: {{{ >>> Entries.objects.annotate(clue_count=Count('clues__ID')) [] }}} to the aggregation tests causes a failure on MySQL/MyISAM (not tested on InnoDB since aggregation fixtures won't load there): {{{ ====================================================================== FAIL: Doctest: modeltests.aggregation.models.__test__.API_TESTS ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/kmt/tmp/django/trunk/django/test/_doctest.py", line 2180, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for modeltests.aggregation.models.__test__.API_TESTS File "/home/kmt/tmp/django/trunk/tests/modeltests/aggregation/models.py", line unknown line number, in API_TESTS ---------------------------------------------------------------------- File "/home/kmt/tmp/django/trunk/tests/modeltests/aggregation/models.py", line ?, in modeltests.aggregation.models.__test__.API_TESTS Failed example: Entries.objects.annotate(clue_count=Count('clues__ID')) Exception raised: Traceback (most recent call last): File "/home/kmt/tmp/django/trunk/django/test/_doctest.py", line 1267, in __run compileflags, 1) in test.globs File "<doctest modeltests.aggregation.models.__test__.API_TESTS[75]>", line 1, in <module> Entries.objects.annotate(clue_count=Count('clues__ID')) File "/home/kmt/tmp/django/trunk/django/db/models/query.py", line 148, in __repr__ data = list(self[:REPR_OUTPUT_SIZE + 1]) File "/home/kmt/tmp/django/trunk/django/db/models/query.py", line 163, in __len__ self._result_cache.extend(list(self._iter)) File "/home/kmt/tmp/django/trunk/django/db/models/query.py", line 281, in iterator for row in self.query.results_iter(): File "/home/kmt/tmp/django/trunk/django/db/models/sql/query.py", line 241, in results_iter for rows in self.execute_sql(MULTI): File "/home/…   kmtracey   0 0 0 0 0 0
10289 2009-02-17 22:22:00 2013-02-28 10:15:36 2019-06-24 02:06:49.725407 Unreviewed closed Database layer (models, ORM)     master fixed Postgresql aggregate support version check is hypersensitive Using population !StdDev and Variance, I get the error {{{PostgreSQL 8.2 to 8.2.4 is known to have a faulty implementation of VAR_POP. Please upgrade your version of PostgreSQL.}}} However, my PostgreSQL version is 8.2.11.   ikelly   0 0 0 0 0 0
10290 2009-02-17 22:57:16 2013-02-28 10:15:36 2019-06-24 02:06:50.385538 Unreviewed closed Database layer (models, ORM)     master fixed grouping with extra_selects produces invalid sql From [9838] on, I'm getting aggregation_regress test failures in Oracle, apparently because annotations with extra selects are adding the extra select aliases into the group by list. This produces invalid SQL (at least in Oracle), since you can't use column aliases defined at the same level within a group by clause. The attached patch uses the extra select expression itself in the group by, rather than the alias. This passes the tests across all four included backends, and seems to work in general as long as the expression is not a scalar subquery.   ikelly   0 0 0 0 0 0
10425 2009-03-07 04:59:48 2013-02-28 10:15:36 2019-06-24 02:08:18.633281 Accepted closed Database layer (models, ORM)     master fixed Bad SQL generated for Book.objects.values('author').annotate(Count('author')).count() Observed with SVN revision 9984: Model: {{{ class Book(models.Model): title = models.CharField(max_length=200) author = models.CharField(max_length=200) }}} When using values() with annotate(), the count() method generates bad SQL: {{{ $ python manage.py shell Python 2.6.1 (r261:67515, Dec 6 2008, 16:42:21) [GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> from example.models import * >>> from django.db.models import Count >>> qs = Book.objects.values('author').annotate(Count('author')) >>> qs.count() Traceback (most recent call last): File "<console>", line 1, in <module> File "/Users/kevin/django/bug/annotate_count/django/db/models/query.py", line 329, in count return self.query.get_count() File "/Users/kevin/django/bug/annotate_count/django/db/models/sql/query.py", line 345, in get_count number = obj.get_aggregation()[None] File "/Users/kevin/django/bug/annotate_count/django/db/models/sql/query.py", line 317, in get_aggregation result = query.execute_sql(SINGLE) File "/Users/kevin/django/bug/annotate_count/django/db/models/sql/query.py", line 2097, in execute_sql cursor.execute(sql, params) File "/Users/kevin/django/bug/annotate_count/django/db/backends/util.py", line 19, in execute return self.cursor.execute(sql, params) File "/Users/kevin/django/bug/annotate_count/django/db/backends/sqlite3/base.py", line 190, in execute return Database.Cursor.execute(self, query, params) OperationalError: near "FROM": syntax error }}} The SQL that gets generated is malformed: {{{ SELECT FROM (SELECT "example_book"."author" AS author, COUNT("example_book"."author") FROM "example_book" GROUP BY "example_book"."author") subquery }}}   kmassey values annotate count 0 0 0 0 0 0
10574 2009-03-21 03:43:19 2013-02-28 10:15:36 2019-06-24 02:09:55.582705 Accepted closed Database layer (models, ORM)     master fixed Remove unnecessary ordering in values() queries The ORM applies any ordering (such as default ordering given by `Meta.ordering`) all the time. For this model: {{{ #!python class Item(models.Model): name = models.CharField(max_length=10) data = models.IntegerField() class Meta: ordering = ["name"] }}} This is redundant in `values()` queries like this: {{{ #!python Item.objects.values("data") }}} Even worse, it leads to incorrect results in aggregate queries like this one: {{{ #!python Item.objects.values("data").annotate(Count("id")) }}} Normally, that would return the number of entries for each data value. However, due to the ordering by name being included, we group by (data, name), which affects the result. The solution is to realise that the ordering columns aren't going to feature in the result and remove them. It can be worked around, once you realise the problem, although that last part isn't easy (it took me more than a few minutes): {{{ #!python Items.objects.values("data").annotate(Count("id")).order_by() }}} but Django has enough information to work this out itself. (I'm going to put this in the aggregation category, since that's where the real apparent bug emerges and people will be looking there for similar things, I guess.) mtredinnick mtredinnick   0 0 0 0 0 0
10626 2009-03-25 21:08:14 2013-02-28 10:15:36 2019-06-24 02:10:29.259138 Unreviewed closed Database layer (models, ORM)     1.1-beta duplicate Default model ordering affects annotation query Example models without default orderings: {{{ class Author(models.Model): id = models.IntegerField(primary_key=True, help_text='Uniquely identifies an author.') name= models.CharField(max_length=200, help_text="Author's first name.") class Book(models.Model): id = models.IntegerField(primary_key=True, help_text='Uniquely identifies a book.') title = models.CharField(max_length=200, help_text='The title of this book.') author = models.ForeignKey(Author, db_column='author_id', help_text='The author of this book.') price = models.FloatField( help_text='Price of the book.') inventory = models.IntegerField( help_text='Copies of book in the store.') }}} Use values() and annotate() to determine the number of books at each price. This works as I expected: {{{ >>> q = Book.objects.values('price').annotate(Count('price')) >>> list(q) [{'price': 7.9900000000000002, 'price__count': 2}, {'price': 9.9900000000000002, 'price__count': 1}] }}} Now add default orderings to the models: {{{ class Author(models.Model): id = models.IntegerField(primary_key=True, help_text='Uniquely identifies an author.') name= models.CharField(max_length=200, help_text="Author's first name.") class Meta: ordering = ['id'] class Book(models.Model): id = models.IntegerField(primary_key=True, help_text='Uniquely identifies a book.') title = models.CharField(max_length=200, help_text='The title of this book.') author = models.ForeignKey(Author, db_column='author_id', help_text='The author of this book.') price = models.FloatField( help_text='Price of the book.') inventory = models.IntegerField( help_text='Copies of book in the store.') class Meta: ordering = ['id'] }}} And repeat the query: {{{ >>> q = Book.objects.values('price').annotate(Count('price')) >>> list(q) [{'price': 9.990000000…   kmassey values annotate ordering 0 0 0 0 0 0
10666 2009-03-30 21:49:38 2013-02-28 10:15:36 2019-06-24 02:10:55.405034 Accepted closed Database layer (models, ORM)     master fixed Aggregate with inherited columns does not work as expected {{{ class Thing(models.Model): user = models.ForeignKey("auth.user") creation_date = models.DateTimeField(_('Creation date'), default=datetime.datetime.now) amount = models.PositiveIntegerField() class Book(Thing): blabla = models.ForeignKey("xyz") # does not work Book.objects.filter(user=request.user).aggregate(Sum('amount')) # does work Book.objects.filter(user=request.user).annotate(Sum('amount')) # does work Book.objects.filter(user=request.user).aggregate(Sum('book_ptr__amount')) }}}   julianb   0 0 0 0 0 0
10673 2009-03-31 07:51:56 2013-02-28 10:15:36 2019-06-24 02:10:59.963175 Unreviewed closed Database layer (models, ORM)     master wontfix If the default manager adds an annotation and sets use_for_related_fields, saves can fail. If a model has a custom manager that sets use_for_related_fields = True and overrides get_query_set() to return an annotated query set, then calling save() on instances of that model can fail with ProgrammingError: subquery has too many columns. I am attaching a diff with a test illustrating this behavior.   benanhalt   0 0 0 0 0 0
10766 2009-04-09 01:33:44 2013-02-28 10:15:36 2019-06-24 02:12:01.497991 Accepted closed Database layer (models, ORM)     1.0 fixed Annotate() doesn't error if given a previously defined annotation alias I recently wrote the following code: {{{ classes = classes.annotate(num_students=Count('anchor__child_set__userbit_qsc')) classes = classes.annotate(total_max_student=Sum('sections__num_students')) }}} The second line above (correctly) generated an error for me because the model referenced by "sections" doesn't contain a field named "num_students". However, the error message returned by the exception was as follows: {{{ Cannot resolve keyword 'num_students' into field. Choices are: [long valid list of fields], num_students }}} This confused me for a good while (until I realized that it was my mistake for using the wrong field name). On experimentation, the "num_students" in the list of fields does in fact come from the first annotate call. It's hardly a critical failure; but it seems like poor form to declare a field as "invalid" then promptly list it as one of the valid options... More generally, it seems like that list just lists all annotated fields, which is only correct if you're not doing a join first. I suspect that the fix is on line 1678 or so of django/db/models/sql/query.py (in particular, maybe it needs to use a different/new function on the Options class to get the keys properly?); but I don't know enough of those internals to know that I'm doing the right thing there. I could work up a patch that does this if no one more-experienced feels like it or knows of a good reason not to.   aseering@mit.edu   0 0 0 0 0 0
10906 2009-04-23 10:40:46 2013-02-28 10:15:36 2019-06-24 02:13:35.642291 Accepted closed Database layer (models, ORM)     master fixed Aggregation support absent on postgres < 8.2 Running the test suite on a clean check out of r10628, with PostgreSQL 8.1 and psycopg2, I get numerous errors from the regressiontests/aggregation_regress/, including: {{{ ProgrammingError: function stddev_pop(integer) does not exist ProgrammingError: function stddev_samp(integer) does not exist ProgrammingError: function var_pop(integer) does not exist ProgrammingError: function var_samp(integer) does not exist }}} I believe that these aggregates were first implemented in PostgreSQL 8.2, so either the aggregation code itself or at least the test cases should be conditional on that version. See [10142] for an existing error message on PostgreSQL 8.2 to 8.2.4, which could perhaps be extended downwards?   Richard Davies <richard.davies@elastichosts.com>   0 1 0 0 0 0
10916 2009-04-24 14:39:49 2013-02-28 10:15:36 2019-06-24 02:13:43.023785 Unreviewed closed Database layer (models, ORM)     master duplicate annotate() method doesn't include content_type_id into WHERE clause when used with generic relations Content type must be included to WHERE clause to prevent object_id's collisions. {{{ >>> qs = Car.objects.annotate(gallery__count=Count('galleries')).order_by('-gallery__count') >>> qs.query.as_sql() ('SELECT `cars_car`.`id`, `cars_car`.`brand_id`, `cars_car`.`name`, `cars_car`.`year`, `cars_car`.`slug`, `cars_car`.`image`, `cars_car`.`description`, COUNT(`gallery_gallery`.`id`) AS `gallery__count` FROM `cars_car` LEFT OUTER JOIN `gallery_gallery` ON (`cars_car`.`id` = `gallery_gallery`.`object_id`) GROUP BY `cars_car`.`id` ORDER BY gallery__count DESC', ()) }}}   skam   0 0 0 0 0 0
10924 2009-04-25 10:14:31 2013-02-28 10:15:36 2019-06-24 02:13:48.047713 Unreviewed closed Database layer (models, ORM)     master wontfix Should use variance() and stddev() rather than var_samp() and stddev_samp() on Postgresql < 8.2 As per http://developer.postgresql.org/pgdocs/postgres/release-8-2.html , the aggregation functions var_pop(), var_samp(), stddev_pop(), and stddev_samp() were first introduced in Postgresql 8.2. However, var_samp() and stddev_samp() were merely renamings of the pre-existing aggregates variance() and stddev(), so we could extend support to earlier versions of Postgresql by using those older function names where appropriate.   Richard Davies <richard.davies@elastichosts.com>   0 0 0 0 0 0
10972 2009-04-30 22:25:41 2013-02-28 10:15:36 2019-06-24 02:14:18.819036 Accepted closed Database layer (models, ORM) New feature Normal master duplicate Use Expressions with Annotations It would be nice if expressions could be used inside annotations, i.e. to perform something like the following: {{{ Customer.objects.annotate('total_purchased': Sum(F('customer__order__lineitem__quantity') * F('customer__order__lineitem__price'))) }}}   me@donaldrichardson.net expression aggregation aggregates annotation 0 1 1 0 0 0
11088 2009-05-12 22:59:14 2013-02-28 10:15:36 2019-06-24 02:15:33.483869 Unreviewed closed Database layer (models, ORM)     1.1-beta invalid Aggregation problem, table JOINed twice I don't know if I'm doing something wrong but I've tried to compile all the information needed to track this one. === Models === video/models.py {{{ class Video(models.Model): name = models.TextField() dir = models.TextField() videoclass = models.ForeignKey('Videoclass') status = models.CharField(max_length=24) date = models.DateTimeField() duration = models.FloatField() width = models.IntegerField() height = models.IntegerField() displayname = models.TextField() published = models.IntegerField() views = models.IntegerField() ratesum = models.IntegerField() ratenum = models.IntegerField() }}} statistics/models.py {{{ class VisitorAction(models.Model): name = models.CharField(max_length = 200) def __unicode__(self): return self.name class VisitorLog(models.Model): visitor = models.ForeignKey("Visitor") video = models.ForeignKey(Video) action = models.ForeignKey(VisitorAction) seek_video = models.FloatField() event_time = models.DateTimeField(default = datetime.datetime.now) domain = models.CharField(max_length = 128) }}} === Datas === statistics_visitorlog contains 100k+ entries video_video contains 400 entries statistics_visitoraction contains 6 entries ('play', 'seek' ... etc) === The QS === {{{ >>> from video.models import * >>> from django.db.models import Count >>> Video.objects.annotate(play_log = Count('visitorlog')).filter(visitorlog__action__name = 'play').order_by('-play_log')[0:10] }}} [Kill the mysqld because it takes forever and have a nice backtrace] {{{ >>> from django.db import connection >>> connection.queries[-1] {'time': '7.180', 'sql': u'SELECT `video_video`.`id`, `video_video`.`name`, `video_video`.`dir`, `video_video`.`videoclass_id`, `video_video`.`status`, `video_video`.`date`, `video_video`.`duration`, `video_video`.`width`, `video_video`.`height`, `video_video`.`displayname`, `video_video`.`published`, `video_video`.`views`, `…   loic@vflow.tv aggregation, join 0 0 0 0 0 0
11090 2009-05-13 01:00:20 2013-02-28 10:15:36 2019-06-24 02:15:34.744397 Unreviewed closed Database layer (models, ORM)     master wontfix Query.group_by no longer supports MySQL specific behaviour I used to be able to do: {{{ qs = Model.objects.extra(select={'foo': 'custom_aggregate()'}, tables=['table']) qs.query.group_by = ['table.column'] }}} This generated a query like: {{{ SELECT model.a, model.b, custom_aggregate() AS foo FROM model, table GROUP BY table.column }}} As far as I understand, this is exploiting MySQL specific behaviour that supports collapsing multiple values within a group into a single return row, rather than enforcing every column to be either listed in GROUP BY, or be an aggregate, as Postgre does, for example. Now, with the changes from r9805 and later also r9838, when using any kind of group_by value at all, the resulting query will actually list all select, select_related and extra_select fields in the GROUP BY clause, meaning my query is now: {{{ SELECT model.a, model.b, custom_aggregate() AS foo FROM model, table GROUP BY table.column, model.a, model.b, foo }}} I realize that group_by is internal API and Django may not want to support this at all, but in case the change was unintentional, I thought I'd bring it up.   miracle2k   0 0 0 0 0 0
11117 2009-05-14 13:54:26 2013-02-28 10:15:36 2019-06-24 02:15:51.983222 Unreviewed closed Database layer (models, ORM)     1.0 duplicate placeholder confusion when using aggregated query with extra Let's assume something like this: {{{ Book.objects.extra(select={'date': "DATE_FORMAT(timestamp, '%s')"}, select_params=('%%H',), where=["DATE_FORMAT(timestamp, '%%H:%%i') > '%s'"], params=['22:00']).values('date').annotate(cnt=Count('id')) }}} ---- the resulting sql query is: {{{ SELECT DATE_FORMAT(timestamp, '%H') AS `date`, COUNT(id) AS `cnt` FROM `books` WHERE DATE_FORMAT(timestamp, '%H:%i') > '%H' GROUP BY DATE_FORMAT(timestamp, '22:00') ORDER BY timestamp ASC }}} ---- the placeholder values '%H' and '22:00' are interchanged, which is obviously a result of using the GROUP BY here on a user-defined variable with placeholder (--> 'date') .query.as_sql() gives something like {{{ (u"SELECT DATE_FORMAT(timestamp, '%s') AS `date`, COUNT(id) AS `cnt` FROM `books` WHERE DATE_FORMAT(timestamp, '%H:%i') > '%s' GROUP BY DATE_FORMAT(timestamp, '%s') ORDER BY timestamp ASC", (u'%H', u'%H', u'22:00')) }}} nobody slide21@web.de   0 0 0 0 0 0
11256 2009-06-04 00:55:36 2013-02-28 10:15:36 2019-06-24 02:17:19.924764 Ready for checkin closed Database layer (models, ORM)     master fixed Fail loudly and clearly when an Annotation alias matches a field name. Continued from [http://groups.google.com/group/django-users/browse_thread/thread/b1ef13c597b6dd15 a django-users thread] Given the following two models: {{{ class Author(models.Model): last_updated = models.DateField() class Book(models.Model): author = models.ForeignKey(Author, related_name='books') pubdate = models.DateField() }}} The following annotation query will produce unexpected results: {{{ authors = Author.objects.annotate(last_updated=Max('books__pubdate')) }}} And it may not raise an error until you combine it with other parts of the queryset api, like order_by: {{{ authors = Author.objects.annotate(last_updated=Max('books__pubdate')).order_by('last_updated') }}} While it's true that these invalid queries are the developer's fault, it's not at all obvious what's gone wrong. Unless there is some valid case for clobbering your own namespace, I suggest that instead of leaving this behavior defined by the particular DB and query, an Exception be raised to let the developer know they've made a mistake before it hits the SQL level.   donspaulding   0 1 0 0 0 0
11612 2009-07-31 16:58:20 2013-02-28 10:15:36 2019-06-24 02:21:08.515870 Unreviewed closed Database layer (models, ORM)     1.0 invalid Model field 'Default' argument doesn't work as documented According to the docs (I am using 1.0.2 final) at http://docs.djangoproject.com/en/1.0/topics/db/models/ "default The default value for the field. This can be a value or a callable object. If callable it will be called every time a new object is created." But the behavior I'm seeing looks like this: {{{ >>> from application.models import * >>> wi,il,ny = OptsState(State='Wisconsin',Abbr='WI'), OptsState(State='Illinois',Abbr='IL'),OptsState(State='New York',Abbr='NY') >>> wi.uuid u'02b01c71-f2ae-4d5f-82b1-88660521826a' >>> il.uuid u'02b01c71-f2ae-4d5f-82b1-88660521826a' >>> ny.uuid u'02b01c71-f2ae-4d5f-82b1-88660521826a' }}} The model looks like this: {{{ class OptsState(models.Model): uuid = models.CharField(primary_key=True, editable=False, default=str(uuid.uuid4())) State = models.CharField(max_length=16) #Wisconsin, etc... Abbr = models.CharField(max_length=16) #wi, etc... def __unicode__(self): return self.State }}} Note, I'm using CharField for simplicity's sake. I have been using a subclass that returns 'uuid' from db_type for my database server. I've tried a number of other field classes as well but the result is the same. It seems to me that it calls uuid.uuid4() ever time a new model is created, but not every time a new object is created.   andyortlieb default,value,model,field 0 0 0 0 0 0
11789 2009-08-27 13:48:23 2013-02-28 10:15:36 2019-06-24 02:23:03.628951 Accepted closed Database layer (models, ORM) Bug Normal 1.1 fixed Aggregates ignore none() {{{ Model.objects.all().aggregate(Max('field')) }}} and {{{ Model.objects.none().aggregate(Max('field')) }}} seem to return the same thing. Aggregates pay attention to filters, but they seem to ignore the none() method. This isn't a common use, so it might not be worth fixing, except for correctness. noah alexr aggregates 0 1 1 0 0 0
11802 2009-08-29 19:47:49 2013-02-28 10:15:36 2019-06-24 02:23:11.992847 Unreviewed closed Database layer (models, ORM)     1.1 invalid Wrong use of aggregation module may lead to non-deterministic bugs Assuming that an AJAX query posts (start, limit) for retrieving Polls (Django tutorial), writing the following code leads to request.POST problem. {{{ #!python from django.core import serializers from django.http import HttpResponse from django.db.models import Count from polls import Poll def respond(rows, totalCount): data = serializers.serialize('json', rows) response = "{'success': true, 'totalCount':%d, 'rows':%s }" % (totalCount, data) return HttpResponse(response, mimetype="application/javascript") def listPolls(request): start = request.POST['start'] limit = request.POST['limit'] rows = Vehicle.objects.all()[start:start+limit] totalCount = Vehicle.objects.aggregate(Count('id')) return respond(rows, totalCount) }}} surprisingly, fixing the code to: {{{ #!python totalCount = Vehicle.objects.aggregate(Count('id'))['id__count'] }}} fixes the request.POST exception. The issue is that the django error report about request.POST not having a key named 'start' or 'limit' distracts the programmer to debugging the front end AJAX code rather than focusing on the Python bug. It also may indicate a more fundamental issue that exhibits random behavior.   AmirHabibi   0 0 0 0 0 0
11822 2009-09-03 01:00:46 2013-02-28 10:15:36 2019-06-24 02:23:24.662678 Unreviewed closed Database layer (models, ORM)     1.1 invalid Slugify check for existing slugs in table Slugify would be more useful if it had an option to set the field name to check against for existing slugs with the same name   amites slug, slufigy 0 0 0 0 0 0
11945 2009-09-25 09:12:45 2013-02-28 10:15:36 2019-06-24 02:24:49.093552 Unreviewed closed Database layer (models, ORM)     1.1 duplicate Aggregation on filter got the wrong result Aggregation on complex filter logic will lead to faulty. I prepared a simple project to reproduct this fault. In this project, some of the following queries will get the wrong results: {{{ > Tag.objects.distinct().filter(entries__when__year=2009).annotate(aggr = Count('entries')) [<Tag: 1 aggr: 10>, <Tag: 2 aggr: 10>, <Tag: 3 aggr: 1>] # It's right > Tag.objects.distinct().filter(entries__when__year=2009).annotate(aggr = Count('entries')).filter(entries__tags__token = '1').exclude(token='1') [<Tag: 2 aggr: 100>, <Tag: 3 aggr: 1>] # Ooops, it's wrong. > Tag.objects.distinct().filter(entries__when__year=2009).filter(entries__tags__token = '1').exclude(token='1').annotate(aggr = Count('entries')) [<Tag: 2 aggr: 100>, <Tag: 3 aggr: 1>] # the same wrong result # let's try Sum > Tag.objects.distinct().filter(entries__when__year=2009).annotate(aggr = Sum('entries__visits')) [<Tag: 1 aggr: 55>, <Tag: 2 aggr: 55>, <Tag: 3 aggr: 1>] # It's OK > Tag.objects.distinct().filter(entries__when__year=2009).filter(entries__tags__token = '1').exclude(token='1').annotate(aggr = Sum('entries__visits')) [<Tag: 2 aggr: 550>, <Tag: 3 aggr: 1>] # wrong }}}   jay   0 0 0 0 0 0
11962 2009-09-29 01:09:23 2013-02-28 10:15:36 2019-06-24 02:24:59.671543 Unreviewed closed Database layer (models, ORM)     1.1 duplicate Annotate with "extra" triggers Traceback (bad SQL) I have a query which performs a fairly complex "extra query" (about 10 sub-select queries). When I added the annotate() call to the chain, I started getting the following traceback. {{{ #select is a dict of SELECTS. Profile.profilekeyword_set.select_related().filter(approved=True).extra(select=select).annotate(anchors=Count('keyword__anchor')).select_related() }}} {{{ .... /usr/lib/python2.5/pprint.pyc in _safe_repr(object, context, maxlevels, level) 290 return format % _commajoin(components), readable, recursive 291 --> 292 rep = repr(object) 293 return rep, (rep and not rep.startswith('<')), False 294 /usr/lib/python2.5/site-packages/django/db/models/query.pyc in __repr__(self) 66 67 def __repr__(self): ---> 68 data = list(self[:REPR_OUTPUT_SIZE + 1]) 69 if len(data) > REPR_OUTPUT_SIZE: 70 data[-1] = "...(remaining elements truncated)..." /usr/lib/python2.5/site-packages/django/db/models/query.pyc in __len__(self) 81 self._result_cache = list(self.iterator()) 82 elif self._iter: ---> 83 self._result_cache.extend(list(self._iter)) 84 return len(self._result_cache) 85 /usr/lib/python2.5/site-packages/django/db/models/query.pyc in iterator(self) 236 model_cls = deferred_class_factory(self.model, skip) 237 --> 238 for row in self.query.results_iter(): 239 if fill_cache: 240 obj, _ = get_cached_row(self.model, row, /usr/lib/python2.5/site-packages/django/db/models/sql/query.pyc in results_iter(self) 285 resolve_columns = hasattr(self, 'resolve_columns') 286 fields = None --> 287 for rows in self.execute_sql(MULTI): 288 for row in rows: 289 if resolve_columns: /usr/lib/python2.5/site-packages/django/db/models/sql/query.pyc in execute_sql(self, result_type) 2367 ret…   erikcw annotate, extra 0 0 0 0 0 0
12270 2009-11-27 11:54:24 2013-02-28 10:15:36 2019-06-24 02:28:18.412541 Unreviewed closed Database layer (models, ORM)     1.1 duplicate Wrong SQL generated with annotated fields and ORed Q objects These are the models I have: A {{{Language}}} model, and {{{Text}}} with fkeys to {{{Language}}}: {{{language}}} (related_name={{{'texts1'}}} and {{{target_language}}} (related_name={{{'texts2'}}}). I want to do a query on languages that have either at least one item in texts1 or in texts2. {{{ from django.db.models import Count, Q languages = Language.objects.all().annotate(num_texts1=Count('texts1'), num_texts2=Count('texts2')) languages = languages.filter(Q(num_texts1__gt=0) | Q(num_texts2__gt=0)) }}} Now I'd assume the generated query contains a {{{HAVING}}} clause with two conditions {{{OR}}}ed in it, but no. This is what {{{_as_sql()}}} returns: {{{ ('SELECT U0."id" FROM "localsite_language" U0 LEFT OUTER JOIN "localsite_text" U1 ON (U0."id" = U1."target_language_id") LEFT OUTER JOIN "localsite_text" U2 ON (U0."id" = U2."language_id") GROUP BY U0."id", U0."name", U0."slug", U0."original_name" HAVING (COUNT(U1."id") > %s AND COUNT(U2."id") > %s )', (0, 0)) }}} In the {{{HAVING}}} clause there's an {{{AND}}} instead of an {{{OR}}} which causes wrong query results. Am I missing something here myself or is this a bug?   RaceCondition   0 0 0 0 0 0
12597 2010-01-13 00:33:33 2013-02-28 10:15:36 2019-06-24 02:31:49.502455 Unreviewed closed Database layer (models, ORM)     1.1 duplicate somefield__isnull=False produce wrong SQL Hi I have two models Model1 Model2, extending another model Model0(not abstract). I'm trying query Model0 and to filter only the models that have relation to Model1 objects = list(Model0.objects.filter(model2__isnull=False) which result with a SQL WHERE "myapp_model0"."id" IS NOT NULL objects = list(Model0.objects.filter(model2__isnull=True) which result with a SQL WHERE "myapp_model2"."model0_ptr_id" IS NULL' The first SQL and the second is right. When using ~Q to negate the second I get what I want. Thanks   benc   0 0 0 0 0 0
12598 2010-01-13 00:37:51 2013-02-28 10:15:36 2019-06-24 02:31:50.141628 Unreviewed closed Database layer (models, ORM)     1.1 duplicate somefield__isnull=False produce wrong SQL Hi I have two models Model1 Model2, extending another model Model0(not abstract). I'm trying query Model0 and to filter only the models that have relation to Model1 {{{ objects = list(Model0.objects.filter(model2__isnull=False) }}} which result with a SQL {{{ WHERE "myapp_model0"."id" IS NOT NULL }}} {{{ objects = list(Model0.objects.filter(model2__isnull=True) }}} which result with a SQL {{{ WHERE "myapp_model2"."model0_ptr_id" IS NULL' }}} The first SQL and the second is right. When using ~Q to negate the second I get what I want. Thanks   benc   0 0 0 0 0 0
12625 2010-01-16 15:59:47 2013-02-28 10:15:36 2019-06-24 02:32:07.570783 Unreviewed closed Database layer (models, ORM)     master invalid .filter(foo__in= duplicates http://docs.djangoproject.com/en/dev/ref/models/querysets/#in SELECT ... WHERE id IN (1, 3, 4); There is no JOIN, and yet: eps all have the same parent: ITA. {{{ >>> from main.models import Client, Show, Location, Episode >>> Location.objects.all() [<Location: Holladay>, <Location: Multnomah>, <Location: ITA>] >>> show = Show.objects.get(slug='January_2010_Meeting') >>> eps = Episode.objects.filter(show=show) >>> Location.objects.filter(episode__in=eps) [<Location: ITA>, <Location: ITA>, <Location: ITA>] }}} I expected {{{ >>> Location.objects.filter(episode__in=eps) [<Location: ITA>] }}} I am pretty sure this used to work as described. hmmm... {{{ In [15]: Location.objects.filter(id__in=[9,9,9]) Out[15]: [<Location: ITA>] }}}   CarlFK   0 0 0 0 0 0
12687 2010-01-25 19:30:15 2013-02-28 10:15:36 2019-06-24 02:32:48.104893 Accepted closed Database layer (models, ORM)     1.2 fixed Using exclude on a queryset with an annotate field give attribute error. When using '''annotate''' on the ''queryset'' of a model that has a ''foreignkey'' relation, you may not use '''exclude''' towards relations afterwards. (See appended code for example) If you were to use '''annotate''' on the model that is pointed at with the ''foreignkey'', '''exclude''' with relations still work. '''Exclude'''ing before using annotate always works. Tested with django.VERSION (1, 1, 0, 'final', 0) on python 2.4.3, was also tested on the 2010.01.22 with the latest SVN. == SQL for creating example table == {{{ #!sql BEGIN; CREATE TABLE "rootnode" ( "id" serial NOT NULL PRIMARY KEY, "somefield" integer CHECK ("somefield" >= 0) NOT NULL); CREATE TABLE "childnode" ( "id" serial NOT NULL PRIMARY KEY, "parent_id" integer NOT NULL REFERENCES "rootnode" ("id") DEFERRABLE INITIALLY DEFERRED, "oddfield" integer CHECK ("oddfield" >= 0) NOT NULL, "evenfield" integer CHECK ("evenfield" >= 0) NOT NULL); COMMIT; }}} == Code that demonstrates the AttributeError == {{{ #!python from django.db import models from django.db.models import Min class RootNode(models.Model): somefield = models.PositiveIntegerField() class Meta: db_table = u'rootnode' class ChildNode(models.Model): parent = models.ForeignKey('RootNode', null = False) oddfield = models.PositiveIntegerField() evenfield = models.PositiveIntegerField() class Meta: db_table = u'childnode' rn1 = RootNode() rn1.somefield = 2 rn1.save() rn2 = RootNode() rn2.somefield = 3 rn2.save() cn1 = ChildNode() cn1.parent = rn1 cn1.oddfield = 43 cn1.evenfield = 42 cn1.save() # This node has even / odd swaped for 'testing' cn2 = ChildNode() cn2.parent = rn1 cn2.oddfield = 42 cn2.evenfield = 43 cn2.save() # Excluding before the annotates always works. q_set = ChildNode.objects.all().annotate(min_somefield=Min('parent__somefield')) # Works print q_set.exclude(oddfield=43).query print q_set.exclude(min_somefield=3) # Gives wrong result (empty set) print q_s…   AsgeirM annotate exclude AttributeError 0 0 0 0 0 0
12822 2010-02-09 11:33:39 2013-02-28 10:15:36 2019-06-24 02:34:14.372422 Ready for checkin closed Database layer (models, ORM)     master fixed DatabaseError: aggregates not allowed in WHERE clause From [http://groups.google.com/group/django-users/browse_thread/thread/2fbd258cd90bc29c# django-users] ; I have been searching for an existing bug and couldn't find any in the ORM/ORM Aggregation component. The following code works with django 1.1, and returns the expected results, but fails with 1.2 beta 1. It's a basic messaging system, in which you can group messages by conversations : when saving a new Foo object, you can give it an existing Foo id to form a conversation. I want to display the "inbox" for a user, which should be a list with the last message from each conversation. {{{ #!python from django.db import models from django.contrib.auth.models import User class Foo(models.Model): subject = models.CharField(max_length=120) sender = models.ForeignKey(User, related_name='sent_foo') recipient = models.ForeignKey(User, related_name='received_foo') conversation = models.ForeignKey('self', null=True, blank=True) from django.db.models import Max def conversations(self, user): tmp = Foo.objects.values('conversation').annotate(Max('id')).values_list('id__max', flat=True).order_by( 'conversation') return Foo.objects.filter(id__in=tmp.filter(recipient=user)) }}} In 1.2 beta 1, with postgresql_psycopg2, it fails with: {{{ DatabaseError: aggregates not allowed in WHERE clause LINE 1: ...d" FROM "mat_foo" WHERE "mat_foo"."id" IN (SELECT MAX("mat_f... }}} The generated SQL queries are a bit different. Here is django 1.2: {{{ #!sql SELECT "mat_foo"."id", "mat_foo"."subject", "mat_foo"."sender_id", "mat_foo"."recipient_id", "mat_foo"."conversation_id" FROM "mat_foo" WHERE "mat_foo"."id" IN (SELECT MAX("mat_foo"."id") AS "id__max" FROM "mat_foo" U0 WHERE U0."recipient_id" = 1 GROUP BY U0."conversation_id") }}} And here is django 1.1 (which works): {{{ #!sql SELECT "mat_foo"."id", "mat_foo"."subject", "mat_foo"."sender_id", "mat_foo"."recipient_id", "mat_foo"."conversation_id" FROM "mat_foo" WHERE "mat_foo"."id" IN (SELECT MAX(U0."id") AS "id__max" F… nobody mat   0 1 0 0 0 0
12823 2010-02-09 12:22:13 2013-02-28 12:54:11 2019-06-24 02:34:15.008473 Accepted closed Database layer (models, ORM) Bug Normal 1.1 fixed Wrong SQL query when using .exclude() Given the following model: {{{ from django.db import models class Book(models.Model): title = models.TextField() chapter = models.ForeignKey('Chapter') class Chapter(models.Model): title = models.TextField() paragraph = models.ForeignKey('Paragraph') class Paragraph(models.Model): text = models.TextField() page = models.ManyToManyField('Page') class Page(models.Model): text = models.TextField() }}} Create the following query: {{{ q = Book.objects.exclude(chapter__paragraph__page__text='foo') }}} From this I would expect to get all books that does not contain the text 'foo' {{{ print q.query }}} This produces: {{{ SELECT `book_book`.`id`, `book_book`.`title`, `book_book`.`chapter_id` FROM `book_book` INNER JOIN `book_chapter` ON (`book_book`.`chapter_id` = `book_chapter`.`id`) WHERE NOT (`book_chapter`.`paragraph_id` IN (SELECT U1.`id` FROM `book_chapter` U1 INNER JOIN `book_paragraph` U2 ON (U1.`paragraph_id` = U2.`id`) INNER JOIN `book_paragraph_page` U3 ON (U2.`id` = U3.`paragraph_id`) INNER JOIN `book_page` U4 ON (U3.`page_id` = U4.`id`) WHERE U4.`text` = foo ) AND `book_chapter`.`paragraph_id` IS NOT NULL) }}} The error here is: {{{ WHERE NOT (`book_chapter`.`paragraph_id` IN (SELECT U1.`id` FROM `book_chapter` U1 }}} Where django tries to compare book_chapter.paragraph_id with book_chapter.id, two fields from the same table. I would expect the query to be: {{{ WHERE NOT (`book_book`.`chapter_id` IN (SELECT U1.`id` FROM `book_chapter` U1 }}} Anssi Kääriäinen <akaariai@gmail.com> olepw   0 1 0 0 0 0
12869 2010-02-15 17:31:36 2013-02-28 10:15:36 2019-06-24 02:34:47.626117 Unreviewed closed Database layer (models, ORM)     1.1 duplicate SELECT (1) AS [a] FROM [my_table] WHERE ([my_table].[id] = ? AND NOT ([my_table].[id] = ? )) (1, 1) Why is Django executing statements such as this: {{{ SELECT (1) AS [a] FROM [my_table] WHERE ([my_table].[id] = ? AND NOT ([my_table].[id] = ? )) (1, 1) }}} This happens when calling is_valid() on a formset created the following way: {{{ MyFormSet = modelformset_factory(Table, fields=['my_field'], extra=0) my_form_set = MyFormSet(request.POST, queryset=Table.objects.all()) }}} where Table and MyForm are as simple as, say: {{{ class Table(models.Model): my_field = models.CharField(max_length=10) class MyForm(forms.ModelForm): class Meta: model = Table }}} Hint: I looked at the call stack and the code responsible for it (in django/forms/models.py) is below: {{{ def _perform_unique_checks(self, unique_checks): import pdb; pdb.set_trace() bad_fields = set() form_errors = [] for unique_check in unique_checks: # Try to look up an existing object with the same values as this # object's values for all the unique field. lookup_kwargs = {} for field_name in unique_check: lookup_value = self.cleaned_data[field_name] # ModelChoiceField will return an object instance rather than # a raw primary key value, so convert it to a pk value before # using it in a lookup. if isinstance(self.fields[field_name], ModelChoiceField): lookup_value = lookup_value.pk lookup_kwargs[str(field_name)] = lookup_value qs = self.instance.__class__._default_manager.filter(**lookup_kwargs) # Exclude the current object from the query if we are editing an # instance (as opposed to creating a new one) if self.instance.pk is not None: qs = qs.exclude(pk=self.instance.pk) }}} Basically the pk is both included for the uniqu…   kmt@ftml.net   0 0 0 0 0 0
13159 2010-03-19 18:44:50 2013-02-28 10:15:36 2019-06-24 02:38:05.081726 Accepted closed Database layer (models, ORM)     master fixed Quote aggregate alias in order by Running the aggregation tests gives an error against Firebird database. {{{ >>> qs = Book.objects.values_list('price').annotate(count=Count('price')).order_by('-count', 'price') }}} Produces the following sql: {{{ SELECT "AGGREGATION_BOOK"."PRICE", COUNT("AGGREGATION_BOOK"."PRICE") AS "COUNT" FROM "AGGREGATION_BOOK" GROUP BY "AGGREGATION_BOOK"."PRICE" ORDER BY count DESC, "AGGREGATION_BOOK"."PRICE" ASC }}} '''count''' in order by clause is not quoted and clashed with reserved the corresponding reserved word. Tested the patch against MySQL and SQLite.   davidelias   0 1 0 1 0 0
13363 2010-04-16 16:59:30 2013-02-28 10:15:36 2019-06-24 02:40:17.076782 Unreviewed closed Database layer (models, ORM)     master wontfix extra fields of Model.objects.extra() can't be filtered {{{ sepp = SomeModel.objects.extra(select={'hiho': """(6371 * acos(cos( radians(%f) ) * cos( radians( geo_lat ) ) * cos( radians( geo_long ) - radians(%f) ) + sin( radians(%f) ) * sin( radians( geo_lat ) ) ))""" % (latitude, longitude, latitude)}) sepp.filter(hiho__lt=30) }}} throws an exception: {{{ Traceback (most recent call last): File "<console>", line 1, in <module> File "/django/db/models/query.py", line 550, in filter return self._filter_or_exclude(False, *args, **kwargs) File "/django/db/models/query.py", line 568, in _filter_or_exclude clone.query.add_q(Q(*args, **kwargs)) File "/django/db/models/sql/query.py", line 1131, in add_q can_reuse=used_aliases) File "/django/db/models/sql/query.py", line 1026, in add_filter negate=negate, process_extras=process_extras) File "/django/db/models/sql/query.py", line 1194, in setup_joins "Choices are: %s" % (name, ", ".join(names))) FieldError: Cannot resolve keyword 'hiho' into field. Choices are: ...all the fields of the model }}}   fetzig queryset extra filter 0 0 0 0 0 0
13442 2010-04-29 09:00:18 2013-02-28 10:15:36 2019-06-24 02:41:08.039445 Unreviewed closed Database layer (models, ORM)     1.1 invalid only() and defer() will always select id Hi there, when you do a query with defer() or only(), you will still execute a SELECT query including the object's id. This makes it impossible to use distinct() on it. {{{ #!python last_5_uploaded_files = UploadFile.objects.order_by('upload_time')[:5] last_changed_list = MainObject.objects \ .filter(upload_file__in=last_5_uploaded_files) \ .only('field_1', 'hostname', 'target', 'modifed_date') \ .distinct() \ .order_by('-modified_date')[:50] response = render_to_response('output/mainobject_list.html', {'object_list': last_changed_list,}) connection.queries print("") # Still includes MainObject.id! WHY? print("current queue: %s" % connection.queries) print("") return response }}} Now if I print the executed SQL using connection.queries I get an SQL statement which includes queryset.id. This is why my distinct won't word - I want a distinct list created without id.[[BR]] On the other hand, '''.values('field_1', 'field_n')''' does work. But this way I do not get the foreign table resolved, just it's id. Please change only() and defer(), so it doesn't select the id in any case. Thanks   mampf   0 0 0 0 0 0
13692 2010-06-03 15:08:52 2013-02-28 10:15:36 2019-06-24 02:43:48.895686 Unreviewed closed Database layer (models, ORM)     1.1 duplicate Wrong ORM in complex filter == With Models: == {{{ class Professional(models.Model): hits = models.PositiveIntegerField() class Article(models.Model): hits = models.PositiveIntegerField() authors = models.ManyToManyField(Professional) class Query(models.Model): hits = models.PositiveIntegerField() author = models.ForeignKey(Professional, blank = True, null = True) }}} == A Query: == {{{ Professional.objects.annotate(article_hits=Sum("article__hits"), query_hits=Sum("query__hits")).exclude(Q(article_hits=None)&Q(query_hits=None)) }}} Produces exactly the same SQL as: {{{ ...exclude(Q(article_hits=None)|Q(advice_hits=None)) ...filter(Q(article_hits=None)&Q(advice_hits=None)) ...filter(Q(article_hits=None)|Q(advice_hits=None)) }}} All of these queries produces a SQL with exactly the same last clause: {{{ .... HAVING (SUM("articles_article"."hits") IS NULL AND SUM("solutions_query"."hits") IS NULL) }}} It doesn't respond to filter/exclude or &| operator. (and also the result is the same)   myneur filter, Q objects 0 0 0 0 0 0
13860 2010-06-30 11:45:25 2013-02-28 09:01:10 2019-06-24 02:45:37.964398 Accepted closed Internationalization New feature Normal master wontfix Translate the output of admin commands We need to enable i18n and actually translate admin commands (shell, syncdb, dbshell, reset, etc.). That's surprising that having excellent i18n tool and all needed settings (settings.LANGUAGE_CODE) users still have to use Django in English in time they may use it in they native language. That makes a '''big difference''' for users. That is fine to enter commands in English but texts must be in defined locale. nobody tonnzor   0 0 0 0 0 0
14011 2010-07-27 04:22:37 2013-02-28 10:15:36 2019-06-24 02:47:21.480339 Accepted closed Database layer (models, ORM)     1.2 fixed QuerySet.none().values('x').query causes "DatabaseError: subquery has too many columns" when used in filters. Just came across this error. {{{ class Test(models.Model): name = models.CharField(max_length=20) test = Test(name='bob') test.save() pks = Test.objects.none().values('pk').query print Test.objects.exclude(pk__in=pks) DatabaseError: subquery has too many columns }}} The query: {{{ SELECT "error_test"."id", "error_test"."name", FROM "error_test" WHERE NOT ( "error_test"."id" IN ( SELECT "error_test"."id", "error_test"."name", FROM "error_test" ) ) }}} Fixes?: * Substitute with {{{.filter(pk__in=[])}}} (possibly overriding none). * Catch and deal with the exception. * Don't let this happen in the code. This should at least raise a more meaningful exception if deemed incorrect. Reason i'd like it to work is because I apply filters dynamically, using some complex logic that sometimes applies a none filter.   skatei <satoru.katei@gmail.com> none query DatabaseError 0 0 0 0 0 0
14016 2010-07-28 13:32:43 2013-02-28 10:15:36 2019-06-24 02:47:24.709227 Unreviewed closed Database layer (models, ORM)     1.2 worksforme SQLite3 problem with date comparison 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]] tzulberti anonymous sqlite, date comparison 0 0 0 0 0 0
14139 2010-08-19 17:19:21 2013-02-28 10:15:36 2019-06-24 02:48:43.035613 Design decision needed closed Database layer (models, ORM)     1.2 duplicate Feature Request: distinct() should support field names I have a table REPORTS containing the columns {id, user, date}. I was attempting to get the row with the largest date for each user. Using Django's ORM I can pretty much get what I want using the queryset definition below. However the resulting query adds parens around the extra() clause: {{{ queryset = Report.objects.extra(select={'lastid':"DISTINCT ON (user_id) id"}) queryset = queryset.order_by('user', '-date') queryset = queryset.values('lastid') }}} According to bug #1413, this is the wrong approach. A better solution is that distinct() should support field names: ''The "select" keyword in extra() should be used to select extra columns which can't be expressed in ORM (like complex expressions, using stored procedures, stuff like that) not to inject arbitrary SQL into a query. A better solution would be to support field names in distinct(), but that's a diffrent thing. After all, there is no reason why the ORM wouldn't put extra select columns on the end, which would also break your code.''   mjs7231   0 0 0 0 0 0
14229 2010-09-07 13:44:52 2013-02-28 10:15:36 2019-06-24 02:49:40.770838 Unreviewed closed Database layer (models, ORM)     master duplicate Postgres backend generates invalid SQL when istartswith and F object are combined. How to reproduce: It's quite easy, just try: {{{ In [1]: from django.db.models import F In [2]: from django.contrib.auth.models import User In [3]: str(User.objects.filter(first_name__istartswith=F('username')).query) Out[3]: 'SELECT "auth_user"."id", "auth_user"."username", "auth_user"."first_name", "auth_user"."last_name", "auth_user"."email", "auth_user"."password", "auth_user"."is_staff", "auth_user"."is_active", "auth_user"."is_superuser", "auth_user"."last_login", "auth_user"."date_joined" FROM "auth_user" WHERE UPPER("auth_user"."first_name"::text) LIKE UPPER() "auth_user"."username"' }}} See the invalid closed UPPER() function at the end. This queryset will ofcourse raise DatabaseError when executed.   ales_zoulek postgres database F 0 0 0 0 0 0
14373 2010-10-01 18:01:45 2013-02-28 10:15:36 2019-06-24 02:51:14.270436 Accepted closed Database layer (models, ORM)     1.2 duplicate annotate() will gladly delete your data Consider the following example: {{{ class Foo(models.Model): name = models.CharField(max_length=100) class Bar(models.Model): name = models.CharField(max_length=100) foos = models.ManyToManyField(Foo, related_name='bars') }}} Create your database, fill it with important data, then do the following: {{{ bars = Bar.objects.all().annotate(foos=Sum('foos')) }}} Now all your data connections are gone. Yay. What happens is that {{{annotate}}} gladly accepts "foos" even if that attribute name is already taken. It then retrieves all the objects from the result set and proceeds to destroy your data by assigning aggregated values to your precious related manager. The manager then happily swallows the integer it receives and goes to delete all the relations. Possible fixes: * Make {{{annotate}}} call {{{delattr}}} before calling {{{setattr}}} * Make {{{annotate}}} raise an exception when passed an already existing attribute Also: * Make the many-to-many manager think for a while before it accepts 5 or any other integer as the new relation set carljm patrys   0 0 0 0 0 0
14387 2010-10-04 11:20:48 2013-02-28 10:15:36 2019-06-24 02:51:23.140834 Unreviewed closed Database layer (models, ORM)     1.2 invalid pre_save problem with inherrited model Hello. I have a base-class and a child-class. The child-class has a pre_save signal and it has a list of related items to it. when testing for save action django raises DoesNotExist exception. Traceback follows: Thank you for the time spent on the Django project File "../children_pre_save_problem/test_b/tests.py", line 9, in test1_inc_num invo.save() File "/usr/lib/pymodules/python2.6/django/db/models/base.py", line 410, in save self.save_base(force_insert=force_insert, force_update=force_update) File "/usr/lib/pymodules/python2.6/django/db/models/base.py", line 432, in save_base signals.pre_save.send(sender=origin, instance=self, raw=raw) File "/usr/lib/pymodules/python2.6/django/dispatch/dispatcher.py", line 166, in send response = receiver(signal=self, sender=sender, **named) File "/home/iskren/tc/python/children_pre_save_problem/test_b/models.py", line 30, in invoicedoc_pre_save instance.recalc_total() File "/home/iskren/tc/python/children_pre_save_problem/test_b/models.py", line 19, in recalc_total for item in self.item_set.all(): File "/usr/lib/pymodules/python2.6/django/db/models/fields/related.py", line 324, in __get__ self.related.model._default_manager.__class__) File "/usr/lib/pymodules/python2.6/django/db/models/fields/related.py", line 399, in create_manager getattr(instance, attname)} File "/usr/lib/pymodules/python2.6/django/db/models/fields/related.py", line 244, in __get__ raise self.field.rel.to.DoesNotExist   iskren pre_save inheritance inherited save 0 0 0 0 0 0
14410 2010-10-06 16:27:59 2013-02-28 10:15:36 2019-06-24 02:51:37.710299 Unreviewed closed Database layer (models, ORM)     1.2 invalid django.db.models.fields.__init__.py class Field.validate failed The validate failed if a value is a list. e.g. {{{ self._choices = [(u'PE', u'PE'), (u'Img', u'Img'), (u'Unknown', u'Unknown'), (u'Other', u'Other')] value = [u'PE', u'Other'] }}}   ctao db models Field validate 0 1 0 0 0 0
14707 2010-11-17 00:33:37 2013-02-28 10:15:36 2019-06-24 02:54:49.468703 Accepted closed Database layer (models, ORM)     1.3-alpha fixed Allow an annotation to match a field name when using .values on a query set. Ticket http://code.djangoproject.com/ticket/11256 has the unfortunate effect of stopping a values query from working. {{{ class Author(models.Model): last_updated = models.DateField() class Book(models.Model): author = models.ForeignKey(Author, related_name='books') pubdate = models.DateField() }}} {{{ authors = Author.objects.values("id").annotate(last_updated=Max('books__pubdate')) }}} In this case we are using values to only use that one field and last_updated is no longer overriding anything.   andymckay blocker, regression 0 0 0 0 0 0
15123 2011-01-19 20:03:54 2013-02-28 10:15:36 2019-06-24 02:59:19.235041 Unreviewed closed Database layer (models, ORM)     1.3-alpha invalid models Meta's db_table and ManyToManyField Given both models as follows: {{{ class P(AuditModel): description = models.CharField(max_length=50, unique=True) class Meta: db_table = 'P' class XSummary(AuditModel): p = models.ManyToManyField(P, blank = True, null = True, ) class Meta: db_table = 'Summary' }}} The 2 models with cutomized db_table name will generate a relationship table as follows: {{{ CREATE TABLE "SUMMARY_P" ( "ID" NUMBER(11) NOT NULL PRIMARY KEY, "XSUMMARY_ID" NUMBER(11) NOT NULL, "P_ID" NUMBER(11) NOT NULL REFERENCES "P" ("ID") DEFERRABLE INITIALLY DEFERRED, ) ; }}} Now you can see that the table name "SUMMARY_P" combined the cutomized db_table name of both models. But the field "XSUMMARY_ID" still take the mode name -- "XSUMMARY", not the db_table "SUMMARY". Franckly, I would like to have the field "XSUMMARY_ID" as "field "SUMMARY_ID". Any feedback or fix on the issue ?   ctao   0 0 0 0 0 0
16018 2011-05-13 09:24:58 2013-02-28 10:15:36 2019-06-24 03:09:03.596386 Unreviewed closed Database layer (models, ORM) Bug Normal 1.3 duplicate Aggregation annotate(Max()) nonoptimal query. I've asked this question in [https://groups.google.com/group/django-users/browse_thread/thread/615f23d359908b77?hl=ru django-users] and got advice to report. Here is the point. Model: {{{ class Home (models.Model): person = models.ForeignKey (Person) state = models.ForeignKey (States) date = models.DateTimeField () host = models.ForeignKey (Hosts) time_spent = models.PositiveIntegerField (null = True) }}} Here is the expression with query it makes: {{{ >>> print Home.objects.values('person').annotate(Max('id')).order_by().query SELECT `main_home`.`person_id`, MAX(`main_home`.`id`) AS `id__max` FROM `main_home` GROUP BY `main_home`.`person_id`, `main_home`.`person_id` ORDER BY NULL }}} GROUP BY formed with double `main_home`.`person_id`. Let's see what happen in this case: {{{ mysql> explain SELECT `main_home`.`person_id`, MAX(`main_home`.`id`) AS `id__max` FROM `main_home` GROUP BY `main_home`.`person_id`, `main_home`.`person_id` ORDER BY NULL; +----+-------------+-----------+-------+---------------+--------------------+---------+------+------+------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-----------+-------+---------------+--------------------+---------+------+------+------------------------------+ | 1 | SIMPLE | main_home | index | NULL | main_home_21b911c5 | 4 | NULL | 4604 | Using index; Using temporary | +----+-------------+-----------+-------+---------------+--------------------+---------+------+------+------------------------------+ }}} In "Extra" you can see "Using temporary" option. Expression execution takes really long time, despite table indexes. If i'll manually remove `main_home`.`person_id` doubling from mysql query, "Using temporary" will disappear and execution runs a times fister. nobody fckin.spam@yahoo.com annotate group_by group twice 0 0 0 0 0 0
17072 2011-10-19 02:17:00 2013-02-28 10:15:36 2019-06-24 03:20:35.508933 Unreviewed closed Database layer (models, ORM) Bug Normal 1.3 needsinfo Unable to chain Annotated Q Objects With OR I am unable to chain annotated Q objects with Non annotated Q Objects. Get an Unknown Column in having clause nobody kevindpostal@gmail.com chain annotated 0 0 0 0 0 0
17681 2012-02-14 09:11:08 2013-02-28 10:15:36 2019-06-24 03:27:06.681536 Unreviewed closed Database layer (models, ORM) Bug Normal 1.3 worksforme Annotating an EmptyQueryset lead to not empty queryset Doing Table.objects.none().annotate(result=Sum("field1")) run a query. On big table, 5 millions row in our case, this lead to a query making mySQL crashed. nobody inscription.tresontani@gmail.com EmptyQueryset, annotate 1 0 0 0 0 0
17727 2012-02-19 19:47:58 2013-02-28 10:15:36 2019-06-24 03:27:36.421909 Unreviewed closed Database layer (models, ORM) New feature Normal 1.4-beta-1 wontfix Multiple values for Fields I think we should support multiple values for fields. Example: """ <= 0: unlimited, 1: default""" emails = models.EmailField(max_length=128, limit=5) Like Drupal is doing, single value field, we store the value in same table; multiple values, we create new table. nobody anonymous multiple values 0 0 0 0 0 0
17954 2012-03-22 23:41:46 2013-02-28 09:00:52 2019-06-24 03:30:04.715178 Ready for checkin closed Testing framework Bug Normal 1.3 fixed django.test.simple.dependency_ordered() allows cyclic dependencies between aliases. (This ticket is split from #17758) The result of this functions depends on the order of aliases for given DB signature (which in turn depends on the order in settings.DATABASES dict) - i.e. if you have a DB with aliases ["A", "B"] and "A" depends on "B" then it will raise an error. If the alias list is ["B", "A"] it will pass. Patch with tests provided in https://github.com/django/django/pull/131 nobody lrekucki   0 1 0 0 0 0
18221 2012-04-27 16:34:25 2013-02-28 10:15:36 2019-06-24 03:32:57.112208 Unreviewed closed Database layer (models, ORM) New feature Normal 1.3 wontfix Add "Length" database function Maybe I'm blind, but I can't find a way to use aggregation functions on the length of a database field. I want to achieve the following: {{{ #!sql SELECT MAX(LENGTH(name)) AS max_name_length FROM table; }}} The natural way to do this with the Django ORM would be something like this: {{{ #!python Model.objects.annotate(name_length=Length('name')).aggregate(Max('name_length')) }}} Unfortunately there is no such `Length()` function. A workaround of doing the annotation would be using `extra(select={'name_length': 'LENGTH(name)'})`, but then the aggregation doesn't work anymore. My suggestion would be to add such a `Length()` function. nobody dbrgn   1 0 0 0 0 0
19290 2012-11-14 04:26:28 2013-02-28 10:15:36 2019-06-24 03:44:27.521338 Unreviewed closed Database layer (models, ORM) Uncategorized Normal 1.4 duplicate 'exclude' on aggregations makes wrong SQL I have a query like this: {{{ qs.annotate(num_a=Sum(field1), num_b=Sum(field2)).exclude(num_a=0, num_b=0) }}} the query returns fewer objects than expected. I have checked the SQL of the query and found it is wrong: {{{ SELECT ......... HAVING (NOT SUM(field1)=0 AND NOT SUM(field2)=0) ....... }}} while what I want is like (just as the [https://docs.djangoproject.com/en/1.4/ref/models/querysets/#exclude documentation] says): {{{ SELECT ......... HAVING (NOT (SUM(field1)=0 AND SUM(field2)=0)) ....... }}} nobody letscan@gmail.com aggregation 0 0 0 0 0 0
19460 2012-12-11 17:01:15 2013-02-28 15:02:11 2019-06-24 03:46:18.437512 Unreviewed closed Uncategorized Uncategorized Normal 1.4 invalid “Unknown password hashing algorithm” when logging in with custom model inheriting from django.contrib.auth.models.User I created a custom user model by inheriting from django.contrib.auth.models.User, and added it to my admin. When I create an instance from MyUser admin, I have two (related) problems: 1- in the admin, the plain password (not uncrypted) is shown in the password field 2- when I try to login in my admin with an instance of MyUser, I get {{{ Unknown password hashing algorithm '<mypassword>'. Did you specify it in the PASSWORD_HASHERS setting }}} is it a bug? how can I fix that? (I'm using Django 1.4.2) '''models.py''' {{{ from django.contrib.auth.models import User class MyUser(User): number = models.IntegerField() }}} '''admin.py''' {{{ class MyUserAdmin(admin.ModelAdmin): fields = ('username', 'password', 'number', 'first_name', 'last_name') admin.site.register(MyUser, MyUserAdmin) }}} nobody anonymous user 0 0 0 0 0 0
19652 2013-01-22 09:16:02 2013-02-28 10:15:36 2019-06-24 03:48:23.486782 Accepted closed Database layer (models, ORM) Bug Release blocker 1.5-beta-1 fixed Fix for #19524 introduced a backward compatiblity issue with related managers on 1.5.X The fix for #19524 which was [https://github.com/django/django/commit/5097d3c5faab2b6582c4cebee2b265fcdbb893eb#L1R698 backported] to the 1.5.X branch caused the following regression: {{{ #!python class ObjectQuerySet(models.query.QuerySet): def extra_qs_method(self): pass class ObjectManager(models.Manager): use_for_related_fields = True def get_query_set(self): return ObjectQuerySet(self.model, using=self._db) class RelatedObject(models.Model): pass class Object(models.Model): related = models.ForeignKey(RelatedObject, related_name='objs') objects = ObjectManager() RelatedObject().objs.extra_qs_method() }}} Raises {{{ AttributeError: 'EmptyQuerySet' object has no attribute 'extra_qs_method' }}} It works perfectly on `master` since `QuerySet.none()` returns an instance of the correct class while setting it's underlying's query to empty and on < 1.5.X since prior to this backport there was no `instance.pk` [https://github.com/django/django/commit/5097d3c5faab2b6582c4cebee2b265fcdbb893eb#L1R695 check] to return an `EmptyQuerySet`. charettes charettes none EmptyQuerySet none 0 1 0 0 0 0
19653 2013-01-22 10:03:38 2013-02-28 10:15:36 2019-06-24 03:48:24.112853 Ready for checkin closed Database layer (models, ORM) Cleanup/optimization Normal master fixed `Manager.get_empty_query_set` should call `get_query_set` Now that `EmptyQuerySet` has been [https://code.djangoproject.com/ticket/19184 removed] calling `none()` on a `QuerySet` subclass returns an instance that subclass: {{{ >>> class MyQuerySet(models.query.QuerySet): pass >>> isinstance(MyQuerySet(MyModel).none(), MyQuerySet) >>> True # On django >= 1.6 }}} This is quite useful and less error prone. However, when one subclass `models.Manager` to return a `QuerySet` subclass they '''must''' override both `get_empty_query_set` and `get_query_set` to have consistent behavior. {{{ class MyManager(models.Manager): def get_query_set(self): return MyQuerySet(self.model, using=self._db) class MyModel(models.Model): objects = MyManager() >>> isinstance(MyModel.objects.none(), MyQuerySet) # Manager.none() calls get_empty_query_set under the hood >>> False >>> isinstance(MyModel.objects.all().none(), MyQuerySet) >>> True }}} Another alternative (better IMHO) is to completely remove `get_empty_query_set` since it's not documented and only used by `Manager.none` and `EmptyManager.get_query_set`. We could make `Manager.none` proxy `QuerySet.none` and `EmptyManager.get_query_set` returns `QuerySet.get_query_self(self).none()`. Attaching two patches that both pass all tests on Python 2.7.3 SQlite. nobody charettes   0 1 0 0 0 0
19935 2013-02-27 21:51:20 2013-02-28 12:18:50 2019-06-24 03:51:24.671016 Unreviewed closed Generic views Bug Normal 1.5-rc-1 invalid Unicode chars in verbose_name results in UnicodeDecodeError instead of 404 in generic views If you name your model in Meta class using verbose_name and you use some non-ASCII character in it, it breaks DetailView for that object. If you call DetailView with existing ID, it works, but when you try to retrieve non-existent object (using non-existent PK), it will return 'UnicodeDecodeError 'ascii' codec can't decode byte 0xc4 in position 0: ordinal not in range(128)' instead of 404. When you append "u" to that string or don't use "verbose_name" at all, it works. Note that you can use UTF-8 chars in verbose_name_plural and it works. And yes, I have "# -*- coding: utf-8 -*-" on the first line of that file. I have named everything with utf-8 characters and I don't have problem with anything other. You can see the traceback here: [http://dpaste.com/hold/1006177/] nobody boloomka@gmail.com utf-8 0 0 0 0 0 0
19937 2013-02-27 22:11:39 2013-02-28 13:27:18 2019-06-24 03:51:25.992133 Unreviewed closed Documentation Bug Normal master fixed Small bug in a documentation code example (Introduction to Class-based views) The page at https://docs.djangoproject.com/en/dev/topics/class-based-views/intro/ says: > > The first is the standard Python way of subclassing and overriding attributes and > methods in the subclass. So that if your parent class had an attribute greeting > like this: > > from django.http import HttpResponse > from django.views.base import View > > class GreetingView(View): > greeting = "Good Day" > > def get(self, request): > return HttpResponse(self.greeting) > > > You can override that in a subclass: > > class MorningGreetingView(MyView): > greeting = "Morning to ya" > The superclass of the last definition is wrong. Correct definition would be: {{{#!python class MorningGreetingView(GreetingView): greeting = "Morning to ya" }}} nobody anonymous   0 0 0 0 0 0

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options:

CREATE TABLE "tickets_full" (
        id int primary key,
        created datetime,
        changetime datetime,
        last_pulled_from_trac datetime,
        stage text,
        status text,
        component text,
        type text,
        severity text,
        version text,
        resolution text,
        summary text,
        description text,
        owner text,
        reporter text,
        keywords text,
        easy boolean,
        has_patch boolean,
        needs_better_patch boolean,
        needs_tests boolean,
        needs_docs boolean,
        ui_ux boolean
    );