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
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
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:
>
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
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. :-)
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
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
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
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
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
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
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
12 matches
Mail list logo
