On 9/4/06, Ned Batchelder <[EMAIL PROTECTED]
> wrote:
You are correct; there are some problems with sync/install in management.py. What you are describing is a variant on a known problem - Ticket #1828. Syncdb duplicates the logic of the install target, but misses installing indicies. On top of that ticket, install doesn't issue a 'post_syncdb' signal. There are also some transaction based problems with the way syncdb installs initial data - as s result of the way transactions are applied, you can end up with problems bootstrapping initial SQL files if those SQL files include cross-application relations.
I am planning to refactor this area when I start playing with test fixtures in the near future. Once I've got my thoughts together, I'll post some ideas for comment.
Yours,
Russ Magee %-)
I've been experimenting with the new test frameworks, and am very
excited about their potential.
I've hit a snag, and am wondering if it reveals a flaw in the current
management.py, or if there is something I don't understand yet (most
likely the latter). Russ's test runner uses management.syncdb() to
create the test database. I've hooked the post_syncdb signal to create
my initial data. It works great.
I've also tried Jason's nose-django plugin, and it uses
management.install(app) to create the test database. This doesn't fire
a signal I can hook, so I wasn't able to create my initial data.
But the difference between the two made me wonder if management.py could
use some clarification. Which is the proper method to create the
database? Do we need both? If so, should both fire the same event so
that initial data can be created in a single way? Sorry to have so many
questions and so few answers. Perhaps there's a simple path here that I
have not found?
You are correct; there are some problems with sync/install in management.py. What you are describing is a variant on a known problem - Ticket #1828. Syncdb duplicates the logic of the install target, but misses installing indicies. On top of that ticket, install doesn't issue a 'post_syncdb' signal. There are also some transaction based problems with the way syncdb installs initial data - as s result of the way transactions are applied, you can end up with problems bootstrapping initial SQL files if those SQL files include cross-application relations.
I am planning to refactor this area when I start playing with test fixtures in the near future. Once I've got my thoughts together, I'll post some ideas for comment.
Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
