Add pre_insert signal to loaddata command

[Jonas H.]

Here's a patch that adds a pre_insert signal to the loaddata command, allowing to do extra modifications on deserialized objects before saving them to the database.

Here's my use case: SQL databases use integer primary keys, MongoDB uses ObjectIds, and I want to re-use SQL-style fixtures (as found in the Django test suite) to test Django MongoDB Engine (the Django MongoDB backend). I think this is a painless way to solve this problem: Very little code changes and doesn't require any ugly hacks.

Would be great if this could be applied!

[Jonas H.]

Any way to get this into trunk soon?

[Julien Phalip]

This sounds like a useful feature, but to stand any chance of inclusion the patch would need some tests and documentation.

[Jonas H.]

Fixed version with tests

[Jonas H.]

Where should the documentation go to? The 'loaddata' section in the commands reference? The testing docs?

[Russell Keith-Magee]

I disagree that a signal is the right way to handle this. Signals, even when unconnected, have a cost, and this would impose a cost on every fixture load (and, by extension, every test in every test run) in order to support what seems to be to be an extreme edge case requirement.

My gut tells me that a better approach would be a custom serializer. That would isolate the extra cost to the specific deserializer that needs the extra data conversion features.

Answering your question about tests: the tests should go in the regressiontests/fixtures_regress test suite; the loaddata command is tested there as a side effect of testing fixtures themselves.

[Jonas H.]

Russell, that's true, although I think that's negligible - running all model tests, I get a difference of half a second (48.3 vs. 47.9 seconds), for Django's ~3500 tests that's an addition of about 3 seconds.

(btw, my question was about documentation, not tests.)

[Jacob]

I find myself agreeing with Russ that a custom serializer is a better approach here. I just can't find a compelling use case for this signal beyond the very specific one you've posted. Wary of feature creep, I'm marking this wontfix.