On 9/6/07, Paul Davis <[EMAIL PROTECTED]> wrote: > > I'm having a bit of a problem using the appname/sql/model.sql custom > sql files. ... > But running: > $ python manage.py sqlcustom root | psql eureka > > Completes wihtout errors. So, I'm fairly certain that the custom sql > is not being run in a single transaction like I would think it should > if I can't specificaly order my scripts so that I populate tables that > are referenced by foreign keys first.
You are correct in that there is no transaction management around the custom loaded SQL. If we were to add transaction management, I agree that the best approach would be to wrap the entire custom SQL block in a single transaction. However, I'm not completely convinced this is a good idea. Your custom SQL script could include BEGIN/END statements. It could include statements that imply a transaction end. In short, there is no way to guarantee that the 'single transaction' guarantee could ever be enforced. I would also suggest that you look at why you are using custom SQL. The 'current best practice' is that custom SQL should only be used for table modifications - adding constraints, new indicies, new non-django columns, etc. If you want to insert data - the sort of thing that causes key errors like the one you describe - then you should be using fixtures. All fixtures _are_ loaded as a single transaction, so errors of the type you describe are avoided. > Plus, I'd assume this is a big reason why all the constraints are > deferred too. Correct. Yours, 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?hl=en -~----------~----~----~----~------~----~------~--~---
