Python Sort
Hi everybody,
I have 3 models:
built-in User model,
class Project(models.Model):
author = models.ForeignKey(User, verbos_name=_('Author'),
related_name='projects')
title = models.charField(_('Title'), max_length=150)
class Vote(models.Model):
project = models.ForeignKey(Project, verbos_name=_('Project'),
related_name='votes')
user = models.ForeignKey(User, verbos_name=_('User'),
related_name='votes')
So users can be authors of the projects and they can vote for the
projects.
I have the view to show list of projects, when I want to order
projects by votes.count
As far as Project model does not contain the Votes field (it is
realised as Many-To-Many table), I do not know how to write DB query
like this:
projects = Project.objects.order_by('votes')
So I decided to take the projects as follows:
projects = Project.object.all()
And then foreach project count the votes number. But is is time-
consuming. Also I do not know if this is true:
for project in projects
project.votes = project.votes.count
projects = sorted(projects, votes)
Do you know any approach to do it on the fly? I mean the most efective
way.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
intcomma ini django admin
Hi there, Im a new django guy here so apology if i am asking a stupid question. Can you comma separate an integer field in the admin interface for example 1 -> 1 10 -> 10 100 -> 100 1000 -> 1,000 I know intcomma does that but how do you do that in admin Thanks very much in advance -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Python Sort
Please don't cross-post the same message to both django-users and django-developers. This question belongs on django-users. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: intcomma ini django admin
Please ask questions about using django on django-users. The topic of this list is the development of Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Python Sort
Ok, I was registered already in django-users, but suddenly was gotten out. Why? So I decided to break the rule. On Jul 23, 4:00 pm, Karen Tracey wrote: > Please don't cross-post the same message to both django-users and > django-developers. This question belongs on django-users. > > Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: memcached-based-cache - timeout=0 does not work as intended by memcached
The only concern in that ticket seems to be that 0 means different things for different cache backends. There may have been some effort towards making them all behave the same when 0 is passed. Personally I prefer the approach of not messing with the value at all, and passing it straight to the configured cache backend. You don't want Django messing with your .extra() or .raw(), so why should it try to magically alter the parameters you pass to your cache backend? Furthermore, correct me if I'm wrong, but: timeout = timeout or self.default_timeout seems like an oversight on the part of whoever wrote that line originally, not some intended functionality to prevent 0 from ever making it to the actual backend. Chances are, if you configured a cache backend for your Django project, you chose one explicitly and have some cognition of how it works. We could could change line this to: timeout = timeout is not None and timeout or self.default_timeout and simply add a big fat warning to the docs stating that 0 means different things on different backends. Thoughts? Tobias On Thu, Jul 22, 2010 at 7:44 AM, Will Hardy wrote: > I thought this was familiar too: < > http://code.djangoproject.com/ticket/6988> > > Is this the ticket you were thinking of? It seems to have been reopened. > > Cheers, > > Will Hardy > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 USA: +1 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Documenting new features: built-in obsolescence of the "versionadded" tag.
Hi everybody, The Django documentation places a strong emphasis on highlighting new/ changed features with lines such as: "New in Django 1.0: Please, see the release notes" Such comments are a useful mental reminder when scanning through the docs, they do however have one downside: built-in obsolescence. With the passage of time (and versions), they will end up referring to long- forgotten Django releases, and become just cruft. My question: how long should these "versionadded" tags remain in the documentation? My $0.02: seeing as only 1.1 and 1.2 are officially supported, and that *in theory* everyone should already be working with those - reminders for earlier versions e.g. 1.0 have become cruft. Any thoughts? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Documenting new features: built-in obsolescence of the "versionadded" tag.
I agree. It's a little odd seeings things flagged "New" that have been around since 1.0. I also like your proposal of removing the notes for unsupported versions. Tobias On Fri, Jul 23, 2010 at 12:06 PM, richardbarran < richardbar...@googlemail.com> wrote: > Hi everybody, > The Django documentation places a strong emphasis on highlighting new/ > changed features with lines such as: > >"New in Django 1.0: Please, see the release notes" > > Such comments are a useful mental reminder when scanning through the > docs, they do however have one downside: built-in obsolescence. With > the passage of time (and versions), they will end up referring to long- > forgotten Django releases, and become just cruft. > My question: how long should these "versionadded" tags remain in the > documentation? My $0.02: seeing as only 1.1 and 1.2 are officially > supported, and that *in theory* everyone should already be working > with those - reminders for earlier versions e.g. 1.0 have become > cruft. > Any thoughts? > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 USA: +1 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Documenting new features: built-in obsolescence of the "versionadded" tag.
On Fri, Jul 23, 2010 at 11:18 AM, Tobias McNulty wrote: > I agree. It's a little odd seeings things flagged "New" that have been > around since 1.0. I also like your proposal of removing the notes for > unsupported versions. > Tobias I think maybe the rendering can just be altered to ignore tags with the old values? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: memcached-based-cache - timeout=0 does not work as intended by memcached
On Fri, Jul 23, 2010 at 8:17 AM, Tobias McNulty wrote: > The only concern in that ticket seems to be that 0 means different things > for different cache backends. > There may have been some effort towards making them all behave the same when > 0 is passed. > Personally I prefer the approach of not messing with the value at all, and > passing it straight to the configured cache backend. You don't want Django > messing with your .extra() or .raw(), so why should it try to magically > alter the parameters you pass to your cache backend? I agree. > Furthermore, correct me if I'm wrong, but: > timeout = timeout or self.default_timeout > seems like an oversight on the part of whoever wrote that line originally, I think that "whoever" was me, and I think you're right that it should have been more like `timeout = self.default_timeout if timeout is None else timeout` (or the equivalent 2.4 syntax). I'd bless a patch making that simple fix. It's very slightly backwards compatible, but almost certainly in a good way, so I'm fine with the change. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Documenting new features: built-in obsolescence of the "versionadded" tag.
That would be also my intend. We could keep the tags in the documentation but could stop the output in the HTML generation. 2010/7/23 Jeremy Dunck : > On Fri, Jul 23, 2010 at 11:18 AM, Tobias McNulty > wrote: >> I agree. It's a little odd seeings things flagged "New" that have been >> around since 1.0. I also like your proposal of removing the notes for >> unsupported versions. >> Tobias > > I think maybe the rendering can just be altered to ignore tags with > the old values? > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Documenting new features: built-in obsolescence of the "versionadded" tag.
On Fri, Jul 23, 2010 at 9:37 AM, Jeremy Dunck wrote: > I think maybe the rendering can just be altered to ignore tags with > the old values? Actually, I think I'd rather just remove them -- plenty of people (including me) read the docs in plain text, and the "versionadded" is just cruft. I'd suggest we strip out any versionadded/changed directives that refer to versions we no longer support. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
firebird backend for django
Hi,
I'm working on django-firebird project and doing some modifications
for work with django 1.2
Right now, I'm trying to pass some tests running the tests suit of
django trunk code and I found the next problem:
django is trying to execute this 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
But, I get the next error:
DatabaseError: (-104, 'isc_dsql_prepare: \n Dynamic SQL Error\n SQL
error code = -104\n Token unknown - line 1, column 157\n DESC --
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')
The problem is with the count field on ORDER BY clause. The sql is
defined as COUNT("AGGREGATION_BOOK"."PRICE") AS "COUNT" and the
count field is upper case (and quoted) then the order by clause must
be:
ORDER BY "COUNT" DESC
Which method can I override to solve this?
Any help?
Thanks in advance.
Maxi.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: firebird backend for django
On Fri, Jul 23, 2010 at 4:30 PM, maxi wrote:
> Hi,
>
> I'm working on django-firebird project and doing some modifications
> for work with django 1.2
> Right now, I'm trying to pass some tests running the tests suit of
> django trunk code and I found the next problem:
>
> django is trying to execute this 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
>
> But, I get the next error:
>
> DatabaseError: (-104, 'isc_dsql_prepare: \n Dynamic SQL Error\n SQL
> error code = -104\n Token unknown - line 1, column 157\n DESC --
> 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')
>
> The problem is with the count field on ORDER BY clause. The sql is
> defined as COUNT("AGGREGATION_BOOK"."PRICE") AS "COUNT" and the
> count field is upper case (and quoted) then the order by clause must
> be:
>
> ORDER BY "COUNT" DESC
>
> Which method can I override to solve this?
> Any help?
>
> Thanks in advance.
>
> Maxi.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
It comes from here:
http://code.djangoproject.com/browser/django/trunk/django/db/models/sql/compiler.py#L328
in get_ordering() on the compiler.
Wherever the logic is that you're uppercasing everything you'll need
to apply it here as well.
Alex
--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: firebird backend for django
On 23 jul, 18:42, Alex Gaynor wrote:
> On Fri, Jul 23, 2010 at 4:30 PM, maxi wrote:
> > Hi,
>
> > I'm working on django-firebird project and doing some modifications
> > for work with django 1.2
> > Right now, I'm trying to pass some tests running the tests suit of
> > django trunk code and I found the next problem:
>
> > django is trying to execute this 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
>
> > But, I get the next error:
>
> > DatabaseError: (-104, 'isc_dsql_prepare: \n Dynamic SQL Error\n SQL
> > error code = -104\n Token unknown - line 1, column 157\n DESC --
> > 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')
>
> > The problem is with the count field on ORDER BY clause. The sql is
> > defined as COUNT("AGGREGATION_BOOK"."PRICE") AS "COUNT" and the
> > count field is upper case (and quoted) then the order by clause must
> > be:
>
> > ORDER BY "COUNT" DESC
>
> > Which method can I override to solve this?
> > Any help?
>
> > Thanks in advance.
> >
> > Maxi.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/django-developers?hl=en.
>
> It comes from
> here:http://code.djangoproject.com/browser/django/trunk/django/db/models/s...
> in get_ordering() on the compiler.
>
> Wherever the logic is that you're uppercasing everything you'll need
> to apply it here as well.
>
Hi Alex,
Thanks for response.
Do you think what SQLCompiler.as_sql is the right place for to do
this ?
Regards.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: firebird backend for django
On Fri, Jul 23, 2010 at 4:56 PM, maxi wrote:
>
>
> On 23 jul, 18:42, Alex Gaynor wrote:
>> On Fri, Jul 23, 2010 at 4:30 PM, maxi wrote:
>> > Hi,
>>
>> > I'm working on django-firebird project and doing some modifications
>> > for work with django 1.2
>> > Right now, I'm trying to pass some tests running the tests suit of
>> > django trunk code and I found the next problem:
>>
>> > django is trying to execute this 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
>>
>> > But, I get the next error:
>>
>> > DatabaseError: (-104, 'isc_dsql_prepare: \n Dynamic SQL Error\n SQL
>> > error code = -104\n Token unknown - line 1, column 157\n DESC --
>> > 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')
>>
>> > The problem is with the count field on ORDER BY clause. The sql is
>> > defined as COUNT("AGGREGATION_BOOK"."PRICE") AS "COUNT" and the
>> > count field is upper case (and quoted) then the order by clause must
>> > be:
>>
>> > ORDER BY "COUNT" DESC
>>
>> > Which method can I override to solve this?
>> > Any help?
>>
>> > Thanks in advance.
>> >
>> > Maxi.
>>
>> > --
>> > You received this message because you are subscribed to the Google Groups
>> > "Django developers" group.
>> > To post to this group, send email to django-develop...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > django-developers+unsubscr...@googlegroups.com.
>> > For more options, visit this group
>> > athttp://groups.google.com/group/django-developers?hl=en.
>>
>> It comes from
>> here:http://code.djangoproject.com/browser/django/trunk/django/db/models/s...
>> in get_ordering() on the compiler.
>>
>> Wherever the logic is that you're uppercasing everything you'll need
>> to apply it here as well.
>>
>
> Hi Alex,
> Thanks for response.
>
> Do you think what SQLCompiler.as_sql is the right place for to do
> this ?
>
> Regards.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
as_sql() seems like a poor place for it, because whatevers returned to
you is already a string, you have no idea what type it us, unless in
firebird all identifiers should be blindly uppercased.
Alex
--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Documenting new features: built-in obsolescence of the "versionadded" tag.
While I know it comes with extra work, I think the contents of the versionadded bits need to be reworked into the body of text. While I can't remember any specific examples, I remember reading docs a few times and coming across versionadded statements that were at the bottom of their section rather than where they would have naturally flowed in the text. On Fri, Jul 23, 2010 at 3:49 PM, Jacob Kaplan-Moss wrote: > On Fri, Jul 23, 2010 at 9:37 AM, Jeremy Dunck wrote: >> I think maybe the rendering can just be altered to ignore tags with >> the old values? > > Actually, I think I'd rather just remove them -- plenty of people > (including me) read the docs in plain text, and the "versionadded" is > just cruft. > > I'd suggest we strip out any versionadded/changed directives that > refer to versions we no longer support. > > Jacob > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: firebird backend for django
On 23 jul, 18:58, Alex Gaynor wrote:
> On Fri, Jul 23, 2010 at 4:56 PM, maxi wrote:
>
> > On 23 jul, 18:42, Alex Gaynor wrote:
> >> On Fri, Jul 23, 2010 at 4:30 PM, maxi wrote:
> >> > Hi,
>
> >> > I'm working on django-firebird project and doing some modifications
> >> > for work with django 1.2
> >> > Right now, I'm trying to pass some tests running the tests suit of
> >> > django trunk code and I found the next problem:
>
> >> > django is trying to execute this 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
>
> >> > But, I get the next error:
>
> >> > DatabaseError: (-104, 'isc_dsql_prepare: \n Dynamic SQL Error\n SQL
> >> > error code = -104\n Token unknown - line 1, column 157\n DESC --
> >> > 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')
>
> >> > The problem is with the count field on ORDER BY clause. The sql is
> >> > defined as COUNT("AGGREGATION_BOOK"."PRICE") AS "COUNT" and the
> >> > count field is upper case (and quoted) then the order by clause must
> >> > be:
>
> >> > ORDER BY "COUNT" DESC
>
> >> > Which method can I override to solve this?
> >> > Any help?
>
> >> > Thanks in advance.
> >> >
> >> > Maxi.
>
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> > Groups "Django developers" group.
> >> > To post to this group, send email to django-develop...@googlegroups.com.
> >> > To unsubscribe from this group, send email to
> >> > django-developers+unsubscr...@googlegroups.com.
> >> > For more options, visit this group
> >> > athttp://groups.google.com/group/django-developers?hl=en.
>
> >> It comes from
> >> here:http://code.djangoproject.com/browser/django/trunk/django/db/models/s...
> >> in get_ordering() on the compiler.
>
> >> Wherever the logic is that you're uppercasing everything you'll need
> >> to apply it here as well.
>
> > Hi Alex,
> > Thanks for response.
>
> > Do you think what SQLCompiler.as_sql is the right place for to do
> > this ?
>
> > Regards.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/django-developers?hl=en.
>
> as_sql() seems like a poor place for it, because whatevers returned to
> you is already a string, you have no idea what type it us, unless in
> firebird all identifiers should be blindly uppercased.
>
Ok, I agree.
But, I'm trying to understand some things:
1). Why if in the SELECT clause count field as defined as
COUNT("AGGREGATION_BOOK"."PRICE") AS "COUNT" using "COUNT" alias
(quote and upercase), django get count (unquote and lowercase) when
add ORDER BY count DESC
2). Where does django get the count field (unquote and lowercase)
instead "COUNT"
Thanks for your help.
Maxi.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: New context template tag
I'm a fan of this proposal. I find that most of the tags I build return a variable to the context rather than just rendering a string. And while a few of the tags I have built require more complexity than the decorator approach could handle, the majority of them would be trivial to make if this were in place. The proposal because it covers a common use case and it fits in with the pattern that Django already employs for tags rather than trying to introduce something new. It's also not trying to over-generalize the problem but make the simple things simple. Creating a tag that takes one or two arguments, processes them, and returns a value to the context feels like it should be simple but right now it's not. For illustration, I'll word the proposal in terms of how it would read in the Django documentation: SHORTCUT FOR SIMPLE TAGS Many template tags take a number of arguments -- strings or a template variables -- and return a string after doing some processing based solely on the input argument and some external information. CONTEXT TAGS Many template tags take a number of arguments -- strings or a template variables -- and return a variable to the context after doing some processing based solely on the input argument and some external information. This feels to me like a natural enhancement to the Django template library. Preston -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Documenting new features: built-in obsolescence of the "versionadded" tag.
On Sat, Jul 24, 2010 at 6:13 AM, Justin Lilly wrote: > While I know it comes with extra work, I think the contents of the > versionadded bits need to be reworked into the body of text. While I > can't remember any specific examples, I remember reading docs a few > times and coming across versionadded statements that were at the > bottom of their section rather than where they would have naturally > flowed in the text. Agreed. It's not just as simple as "strip them out", because in many cases, the language has been forced into awkward contortions in order to describe the incremental improvements that have been made. However, +1 to the idea that we should edit and update to remove the version tags for versions we no longer support (which is to say, the 1.0 and 1.1 version tags in trunk). Yours Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
