In general, the TestCase does a good job of cleaning up the
environment (resetting the DB, etc.), but I've run across an edge case
that might be worth putting upstream.
I have a large codebase running multi-tenant -- lots of sites per WSGI
process, running process-per-request, and it serves those
On May 13, 3:41 pm, Jeremy Dunck wrote:
> In general, the TestCase does a good job of cleaning up the
> environment (resetting the DB, etc.), but I've run across an edge case
> that might be worth putting upstream.
>
> I have a large codebase running multi-tenant -- lots of sites per WSGI
> proces
On 13.05.2011, at 15:52, akaariai wrote:
> On May 13, 3:41 pm, Jeremy Dunck wrote:
>> In general, the TestCase does a good job of cleaning up the
>> environment (resetting the DB, etc.), but I've run across an edge case
>> that might be worth putting upstream.
>>
>> I have a large codebase runn
I'm not that familiar with GFK's and how they work in django, but I just
wanted to check...
Will we have (non-generic) FK support for this, or is that another
can-o-worms that won't get touched for some time?
Regards,
Owen
--
You received this message because you are subscribed to the Google
Hi,
I used the last week to setup the 'test environment' for proof-of-concept'ing
the API we will be implementing. The first thing there is that I setup a (yet)
simplistic template for
1. the form tag, the monolithic approach how I have proposed it
2. multiple tags like proposed by Russell.
Both
http://code.djangoproject.com/ticket/16015
I've uploaded a patch, but changed the status to 'Design Decision Needed'
from 'Accepted.'
The problem is that although my patch follows the existing convention and
results in passing tests in Python 2.6, the Python core developers have made
an import
tl;dr: I've written an alternative TestCase base class which makes
fixture-using tests much more I/O efficient on transactional DBs, and I'd like
to upstream it.
Greetings, all! This is my first django-dev post, so please be gentle. :-) I
hack on support.mozilla.com, a fairly large Django site
On Fri, May 13, 2011 at 6:57 PM, Erik Rose wrote:
> tl;dr: I've written an alternative TestCase base class which makes
> fixture-using tests much more I/O efficient on transactional DBs, and I'd
> like to upstream it.
>
> Greetings, all! This is my first django-dev post, so please be gentle. :-)
You sir, are my personal hero for the day :)
We had also been looking at how we could speed up the fixture loading
(we were almost ready to go so far as to make one giant fixture that
just loaded at the start of the test runner). This is awesome progress
On May 13, 4:57 pm, Erik Rose wrote:
> tl
Also, one thing I'm quickly noticing (I'm a bit confused why its
setup_class and not setUpClass as well), but this wont work with
postgres without changing the DELETE code to work like the test
runner's TRUNCATE foo, bar; (due to foreign key constraints).
On May 13, 9:42 pm, David Cramer wrote:
>
More quick notes. You can do something like this to handle the
flushing:
sql_list = connection.ops.sql_flush(no_style(),
tables, connection.introspection.sequence_list())
for sql in sql_list:
cursor.execute(sql)
Unfortunately, you're
Hello Gregor,
just FYI, one of the guy from django-cms created django-sekizai, which is
used just for that (injecting stuff in template blocks) :
https://github.com/ojii/django-sekizai
Mathieu
--
You received this message because you are subscribed to the Google Groups
"Django developers" g
12 matches
Mail list logo
