Just a quick FYI
-
https://groups.google.com/forum/#!msg/django-developers/N0HEAD1ht8k/GQJ77RLUydsJ
I tried to implement fixture loading in setupClass() and ran into a few
difficulties. I did a lot of profiling though. You get about a factor of 3
speedup for tests that use fixtures. It only re
> I'll be trying to enhance my knowledge base about django request response
and other related stuffs necessary if you please show me some light to get
started or from where actually should I start.
I'd generally think that a decent place to start would be to write up what
some of the documentat
Hi,
Tom has done a great job describing why this has stalled recently. I plan
to pick back up on this now that the book has been released. I agree that
defining the public API is the best first step and the current DEP is not
sufficient in this regard. Before making any internal changes we need
For simplicity, let's assume we have a model A and model B.
class A(models.Model):
name = models.CharField(max_length=200)
class B(models.Model):
a = models.ForeignKey(A)
criteria = models.BooleanField(default = False)
Let's say there's a requirement to find A that doesn't have a B w
If you want to know the SQL generated for any particular queryset, you can
just:
print str(qs.query)
On 11 November 2014 11:39, George Ma wrote:
> For simplicity, let's assume we have a model A and model B.
>
> class A(models.Model):
> name = models.CharField(max_length=200)
>
> class B
#11313 documents a data-loss causing problem that was introduced in 1.1
and still exists in 1.7.
When can https://code.djangoproject.com/ticket/11313 get some attention?
At the very least, warnings should be added to the docs. I provided a doc
patch for 1.5 that was ignored at that time.
Mul
The preference seems to be for option 3, adding a new flag --exit. I have
implemented this and updated the pull request at
https://github.com/django/django/pull/3441.
On Wednesday, October 29, 2014 12:22:42 PM UTC+11, Tim Heap wrote:
>
> Hi all,
>
> I have created a ticket for this (
> https://c
Yes, the actual sql is very close to this one. But I just feel this
approach is like a hack. Because I always have to reverse the logic first
and then reverse again. Not as natural as exists subquery.
On Monday, November 10, 2014 5:53:47 PM UTC-7, Curtis Maloney wrote:
>
> If you want to know th
Can you provide the "natural" SQL version you'd rather see generated?
Something like:
SELECT ... FROM myapp_a WHERE NOT EXISTS (SELECT 1 FROM myapp_b T1 WHERE
T1.a_id = myapp_a.id AND T1.criteria = True)
perhaps?
On 11 November 2014 16:18, George Ma wrote:
> Yes, the actual sql is very close
