Hi Ben,
This issue is tracked in https://code.djangoproject.com/ticket/21719. You'll
see in that ticket why I failed to resolve it, and eventually gave up after
wasting a few day on it.
However, you can avoid it by following two simple good practices (that were
already true before app-loading)
In stable/1.7.x, I'm getting a lot of these warnings:
venv/src/django/django/contrib/sites/models.py:65:
RemovedInDjango19Warning: Model class django.contrib.sites.models.Site
doesn't declare an explicit app_label and either isn't in an application in
INSTALLED_APPS or else was imported before
I think you need to ask this question in django-users group. This group is for
core features and bugs discussions.
--
Alexandr Shurigin
From: Baidyanath Anurag anurag.fa...@gmail.com
Reply: django-developers@googlegroups.com django-developers@googlegroups.com
Date: 12 июня 2014 г. at 1:09:54
T
i am implementing a ticket submission system whose model.py file looks loke
this:
class Ticket(models.Model):
user_id=models.ForeignKey(
User)
category_id=models.ForeignKey(Category)
subject=models.CharField(max_length=100)
message=models.TextField(help_text="enter message")
ti
Given their sample code, my initial impression was that it was indeed
automatic. Looking a bit closer, there seems to be hardcoded logic
inside the DataSource (the thing I'm assuming provides getAllUserIds and
getUsernameById) to specifically fetch all ids and then all names for
those ids. So t
manfre was nice enough to test this patch out on mssql for me. The subset
of tests that use fixtures went from 385 seconds to 158 seconds (+2
failures). The improvement seems to be stable across backends, but isn't
very significant when considering the entire test suite.
I'm going to abandon th
I also do not really know Haskell (I'm sensing a trend...), that said, it
seems to me the cool part of haxl is that it can be automatic -- analagous
to if writing {{ post.author.name }} in a template caused
select_related("author") to automatically be applied to the queryset that
yielded post.
Ale
I'm not great at Haskell, either, but this looks to me to be very similar
to prefetch_related (
https://docs.djangoproject.com/en/dev/ref/models/querysets/#prefetch-related
).
Jacob
On Wed, Jun 11, 2014 at 6:15 AM, Jonathan Slenders <
jonathan.slend...@gmail.com> wrote:
> The "select+1" problem
> Model.objects.filter(...).order_by( F('fld_a').desc(), F('fld_b')).asc()
)
> Model.objects.filter(...).order_by( (F('fld_a')+F('fld_b')).desc() )
I actually really like this. It's simple, clear, and gets around the issues
being discussed. It still requires Expressions to know about orderin
The "select+1" problem is a problem that people often face in Django.
Usually, something like select_related solves it, but I don't think that's
always possible.
Facebook released Haxl today and there's an example of their apprach to the
problem.
https://github.com/facebook/Haxl/tree/master/exam
On Tuesday 10 June 2014 02:48:14 Josh Smeaton wrote:
> > However, I think having some special case code in filter(), annotate()
>
> and anything else that takes expressions would be OK
>
> I strongly disagree with this. Expressions are context insensitive at the
> moment, which means they can be
On Wednesday, June 11, 2014 2:16:06 AM UTC+2, Craig de Stigter wrote:
>
> I reserve judgment on whether STI should be included in core. It works
> fine in a third-party app. Some better support for it in core would be
> helpful, since currently I'm relying on some unsupported stuff that the
>
12 matches
Mail list logo
