#8348: Feature request: -n/--no-act option to syncdb
---------------------------------------------+------------------------------
Reporter: kcarnold | Owner: graham_king
Status: assigned | Milestone: post-1.0
Component: django-admin.py | Version: SVN
Resolution: | Keywords: syncdb
Stage: Design decision needed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------+------------------------------
Changes (by graham_king):
* has_patch: 0 => 1
* stage: Accepted => Design decision needed
Comment:
Attached is a patch that does what Malcolm suggested, a bit wider even, so
that all AppCommand that don't get given an app default to all the apps.
It includes updates to the tests so that they still all pass. I think
defaulting to all the apps makes sense. The only command that could of
been dangerous is 'reset' and it will give you the warning for each app
you try to reset.
But I don't think that's what the bug is about. 'sqlall' prints all the
SQL necessary to create the database, whereas we want to see just the SQL
that syncdb would execute. We want a '--pretend' option (like Gentoo's
portage) which shows what it would do without doing it. And that turns out
to be a tricky problem.
The post_sync signal fire during the syncdb run makes it difficult to know
what is going to run, so we have to go wider than just the syncdb command.
And some of the post_sync listeners reply on being able to 'select' from
tables created in syncdb, so the SQL has to actually run. And transactions
don't cover SQL DDL statements (CREATE, ALTER, etc), at least in MySQL
InnoDB, so we can't rollback.
Here's what I tried doing :
- Just printing out the SQL in syncdb instead of running it. This doesn't
cover the post_sync listeners, and breaks any later selects.
- I tried monkey patching connection.cursor to create pretend cursors that
log instead of executing. This was the most promising, but it breaks
SELECTs down the line.
- I tried starting a transaction and rolling back at the end. That doesn't
work with MyISAM, and more importantly doesn't cover DDL statements, which
is most of what syncdb does.
I think the solution is for --pretend to copy the whole database, using
the 'dumpdata' command and parts of the 'testserver' command, run on the
copy whilst logging the SQL, and drop the copy. That's some heavy lifting,
so I'm setting this back to 'Design Decision Needed' for a yes or no on
database copy, or suggestions on a better way of approaching this.
--
Ticket URL: <http://code.djangoproject.com/ticket/8348#comment:5>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@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-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
