On 9/5/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > 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 %-) > > > >
I ended up running into the issue of not being able to install a plpgsql function from the custom sql scripts so I rearanged alot of how I was doing this stuff. I ended up putting all of my data into a fixture as well. I think the biggest issue is the fact that: $ python manage.py sqlcustom appname gives sql thats in a transaction. It was confusing to have the two different behaviors. Thanks again, Paul Davis --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
