On 8/11/07, Chris Green <[EMAIL PROTECTED]> wrote:
>
> On Aug 9, 7:55 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
> wrote:
> > On 8/9/07, Chris Green <[EMAIL PROTECTED]> wrote:

> > > 2) Setting up users/groups/users manually in the runner gets blown
> > > away by the TestCase architecture.  Works as documented.  However, I'm
> > > not sure where I should put things that should happen post-each syncdb
> > > for testing only.  Should there be a testrunner function that gets
> > > called post each sync or should I create a single TestCase derived
> > > from django.test.TestCase that does the "pre-setup"?
> >
> > I'm not sure I follow. TestCase goes out of its way to avoid
> > interfering with setUp/tearDown methods, and in a TestCase, there is a
> > complete flush after each test, so any setup would need to be rerun on
> > a per-test basis, not a per-sync basis. Can you provide an example of
> > the problem?
>
> Sure: My runner simplified

Ah - I didn't catch on that you were using a customized test runner.
Understood now.

As for how to fix this problem, I have two suggestions.

1) Are you sure you can't just fix this with a static fixture? I can
see that you are using python code to generate the custom permissions,
but are the resulting permissions actually dynamic? Couldn't you just
build them one, capture them, and add them as an 'test_auth' fixture
that you specify each time?

2) Alternatively, have you considered using a syncdb 'post_sync'
trigger? When Django loads an application, it looks for management.py,
and loads it if it is available. This provides an entry point to
listen for the 'post_sync' signal.

This is how Django installs its permissions to begin with. In
management.py, you install a listener on the post_sync message that is
emitted as part of the synchronization process. This signal is
re-emitted as part of a flush (which is what happens at the start of
each test). Look at django.contrib.auth.management for an example of
how to set this up.

> Since strptime() breaks with dates before 1901, it gets serialized out
> with dumpdata but fails on a loaddata()

Ok - this looks to be a python problem (although I'm seeing the issue
with strftime, not strptime). It's worth logging as a ticket so that
it isn't forgotten.

Although this is a python problem, it is a python problem born of a
desire to solve Y2K issues by supporting '04' as 1904. Since we are
only using dates on the backend and in serialization, we can impose
more rigorous datetime formatting constraints, so we might be able to
solve this problem by using an alternate strftime/strptime
implementation that requires 4 digit years. If you want to try your
hand at this, feel free.

Yours,
Russ Magee %-)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to