On Fri, Apr 25, 2008 at 11:40 PM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
> > Have you considered syntax that looks like this instead? :
> > >>> Students.objects.all().aggregate({'average_height': 'height__avg})
> > > {'average_height' : 1.43}
>
> My issue with this syntax is that ev
On Fri, Apr 25, 2008 at 9:35 PM, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> On Apr 22, 9:24 pm, "Nicolas E. Lara G." <[EMAIL PROTECTED]>
> wrote:
>
> > So a QuerySet might be:
> > >>> Students.objects.all().aggregate(height__avg='average_height')
> > {'average_height' : 1.43}
>
> This look
On Fri, 2008-04-25 at 15:12 -0700, Alex Myodov wrote:
> I am among the people interested in this patch.
> But, looking at the patch concepts from the PostgreSQL perspective, I
> wonder whether it will be possible to use it as a base of native
> BIGSERIAL support in Django (it is likely that MySQL
I am among the people interested in this patch.
But, looking at the patch concepts from the PostgreSQL perspective, I
wonder whether it will be possible to use it as a base of native
BIGSERIAL support in Django (it is likely that MySQL supports
something similar, but sqlite needs double-checking).
http://code.djangoproject.com/ticket/399
I notice this ticket has been around for a while, and according to the
comments, was only waiting a Triage member to look it over.
SmileyChris was nice enough to point me over to this group to ask
about it.
Also, the most resent patch was missing the
On Fri, Apr 25, 2008 at 3:26 PM, Ian Kelly <[EMAIL PROTECTED]> wrote:
> Purely in terms of OO design, because it's cleaner. Object
> composition is usually a more appropriate paradigm than class
> inheritance. To take the example from the post that started this
> thread, the relationship bet
On Fri, Apr 25, 2008 at 1:06 PM, AmanKow <[EMAIL PROTECTED]> wrote:
>
> Hmmm... I read the subclassing post. As a non-abstract child is
> essentially a one to one with some syntactical sweetness, I'm still
> not sure how using a one to one field is better suited than
> inheritance for extendi
Hmmm... I read the subclassing post. As a non-abstract child is
essentially a one to one with some syntactical sweetness, I'm still
not sure how using a one to one field is better suited than
inheritance for extending user.
Rajeev J Sebastion wrote:
> Because every app has its own concept/method
The multi-table inheritance stuff in queryset-refactor does
essentially what is mentioned in that article, except it merges the
namespace so that it's easier to use. That being said, it seems that
OneToOneField has been improved as well, for those who want to be
explicit about that link.
On Apr
On Fri, Apr 25, 2008 at 10:23 AM, AmanKow <[EMAIL PROTECTED]> wrote:
> Could you elaborate or point to elaboration on why non-abstract
> inheritance is a bad fit for extending user?
http://www.b-list.org/weblog/2007/feb/20/about-model-subclassing/
--
"Bureaucrat Conrad, you are technically c
this {% firstof %} is even better, more explicit!
and it looks much nicer with filters {% firstof x|escape y|escape %}
better than {{ x|escape|default:y|escape }}
great, thanks for mentioning it.
Sometimes there is more than one place to park your bike :-)
Wolfram
On Fri, Apr 25, 2008 at 5:55
On Fri, Apr 25, 2008 at 8:53 PM, AmanKow <[EMAIL PROTECTED]> wrote:
>
> > Well, I personally have been saying for over a year that inheritance
> > has never been and never will be the right way to do that, so I think
> > y'all know what my answer is...
>
> Could you elaborate or point to elabo
On Fri, Apr 25, 2008 at 10:15 AM, Wolfram Kriesing
<[EMAIL PROTECTED]> wrote:
>
> I guess it might had been discussed, just didnt find anything.
> This extended syntax would really make some writing shorter
>
>user has {{ num_files or "no" }} files
>
> now, you have to write
>
>
On Fri, 25 Apr 2008 05:59:49 -0700, Jan Oberst wrote:
>> Does this differ from just using a slice does?
>>
>>foo = MyModel.objects.all()[0]
>>
>>
> latest() involves an automated ORDER BY after the field you specified in
> Meta's get_latest_by. So it would do the same as a slice[0], if you
>
On Fri, 2008-04-25 at 17:35 +0200, Wolfram Kriesing wrote:
> thank you for all the quick replies.
> Mmmmh, its good to see that it is there, though I think
> {{ num_files or "no" }}
> looks better and is closer to what I would expect ...
> but thats just an aesthetical thing, I guess.
>
Although this is really off-topic in this list, there's also
http://www.djangoproject.com/documentation/templates/#firstof
{% firstof foo bar baz %}
that has the added benefit of outputting nothing if all of foo bar baz
evaluate to False.
On Apr 25, 6:35 pm, "Wolfram Kriesing" <[EMAIL PROTECTED
I noticed that RequestContext uses the dictionary supplied in the
constructor as the base of the stack, then pushes on the the results
of each context processor in turn.
Was this design intentional?
It seems like it might be useful to have the view-specific dictionary
win-- the idea being that t
thank you for all the quick replies.
Mmmmh, its good to see that it is there, though I think
{{ num_files or "no" }}
looks better and is closer to what I would expect ...
but thats just an aesthetical thing, I guess.
thanks a lot
Wolfram
On Fri, Apr 25, 2008 at 4:18 PM, Honza Král <[EM
> Well, I personally have been saying for over a year that inheritance
> has never been and never will be the right way to do that, so I think
> y'all know what my answer is...
Could you elaborate or point to elaboration on why non-abstract
inheritance is a bad fit for extending user?
Thanks!
--~
On Fri, Apr 25, 2008 at 4:15 PM, Wolfram Kriesing
<[EMAIL PROTECTED]> wrote:
>
> I guess it might had been discussed, just didnt find anything.
> This extended syntax would really make some writing shorter
>
>user has {{ num_files or "no" }} files
user has {{ num_files|default:"no"
there is a template filter called default, that does exactly this.
http://www.djangoproject.com/documentation/templates/#default
On Fri, Apr 25, 2008 at 4:15 PM, Wolfram Kriesing
<[EMAIL PROTECTED]> wrote:
>
> I guess it might had been discussed, just didnt find anything.
> This extended syntax
I guess it might had been discussed, just didnt find anything.
This extended syntax would really make some writing shorter
user has {{ num_files or "no" }} files
now, you have to write
user has {% if num_files %} {{ num_files }} {% else %} no {%
endif %} files
Are there an
I would love to see something like AggregateModel returned from
.values().annotate()
it would work like:
for m in Model.objects.values( 'name', 'place' ).annotate(
event__count='number_or_events' )
# the basic data would be available right away
print m['number_or_events'], m['place'], m['nam
On Apr 22, 9:24 pm, "Nicolas E. Lara G." <[EMAIL PROTECTED]>
wrote:
> So a QuerySet might be:
> >>> Students.objects.all().aggregate(height__avg='average_height')
> {'average_height' : 1.43}
This looks really great, but one thing that initially confused me was
the ordering of the arguments - it s
> Does this differ from just using a slice does?
>
>foo = MyModel.objects.all()[0]
>
latest() involves an automated ORDER BY after the field you specified
in Meta's get_latest_by. So it would do the same as a slice[0], if you
sorted it correctly.
--~--~-~--~~~---~-
On Fri, Apr 25, 2008 at 2:17 PM, Patrick J. Anderson
<[EMAIL PROTECTED]> wrote:
> Well, then you could also use:
>
> foo = MyModel.objects.all()[-1]
>
> Wouldn't '_Queryset.latest()' be faster than slicing a big queryset list?
It's slicing on the RDBMS side unless you already evaluated
On Fri, 25 Apr 2008 06:57:06 -0500, Tim Chase wrote:
>> I poked around 'django.db.model.query' this morning and noticed that
>> '_QuerySet' class has 'latest(self, field_name=None)' method. I was
>> wondering if adding 'first(self, field_name=None)' had been considered
>> before.
>>
>> It seems
> I poked around 'django.db.model.query' this morning and noticed that
> '_QuerySet' class has 'latest(self, field_name=None)' method. I was
> wondering if adding 'first(self, field_name=None)' had been considered
> before.
>
> It seems that could be a useful shortcut in some instances.
Does
Hi!
I poked around 'django.db.model.query' this morning and noticed that
'_QuerySet' class has 'latest(self, field_name=None)' method. I was
wondering if adding 'first(self, field_name=None)' had been considered
before.
It seems that could be a useful shortcut in some instances.
--~--~-
29 matches
Mail list logo
