Fixes #16330 Dumpdata specify primary_keys --pks #767

wants to merge 3 commits into


None yet

4 participants

@jacobian jacobian commented on the diff Feb 23, 2013
@@ -21,6 +25,8 @@ class Command(BaseCommand):
help='Use natural keys if they are available.'),
make_option('-a', '--all', action='store_true', dest='use_base_manager', default=False,
help="Use Django's base manager to dump all models stored in the database, including those that would otherwise be filtered or modified by a custom manager."),
+ make_option('--pks', dest='primary_keys', action='append', default=None,
+ help="Only dump objects with given primary keys. Accepts a comma seperated list of keys or '-' to read from stdin. This option is applied to all apps/models."),
jacobian Feb 23, 2013

This points to something weird: if I do dumpdata --pks 2,3,4 app I'll get any object of any type with PKs of 2, 3, or 4. That's... weird. I think a better approach would be to make --pks only work if you've specified a single model. So dumpdata --pks 2,3,4 app.Model will work, but dumpdata --pks 2,3,4 app app2 would through an error.

@jacobian jacobian commented on the diff Feb 23, 2013
@@ -54,6 +61,13 @@ def handle(self, *app_labels, **options):
except ImproperlyConfigured:
raise CommandError('Unknown app in excludes: %s' % exclude)
+ if pks == '-':
+ primary_keys =',')
+ elif pks:
+ primary_keys = pks.split(',')
+ else:
+ primary_keys = False
jacobian Feb 23, 2013

I don't like the idea of reading from stdin; that's unlike how any other management command works. Let's take this part out, I think it's YAGNI.

Django member

merged in 6786920

@timgraham timgraham closed this May 31, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment