Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#22257 closed New feature (fixed)

Write to specified file for dumpdata

Reported by: Gwildor Sok Owned by: ANUBHAV JOSHI
Component: Core (Management commands) Version: dev
Severity: Normal Keywords:
Cc: anubhav9042@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

In response of ticket #22251, I'm opening this as a separate issue like requested. You can read the need for this option there, but basically it removes the current need and practice of redirecting the output of the command to a file, which is often done like this:

$ ./manage.py app1 app2 .. --format=json > dump.json

Removing the need to always do this would open up the possibility to add verbosity during the serialization (see #22251 and a new separate ticket for that).

Concrete proposal:
Add an option to specify a file name to write the output to (under the current working directory), and generate one automatically when one is not specific (e.g. "dump_20140312_1337".json/.xml").

Change History (19)

comment:1 by Aymeric Augustin, 10 years ago

Triage Stage: UnreviewedAccepted

Yes, that makes sense.

comment:2 by ANUBHAV JOSHI, 10 years ago

Cc: anubhav9042@… added
Owner: changed from nobody to ANUBHAV JOSHI
Status: newassigned

comment:3 by ANUBHAV JOSHI, 10 years ago

I have already created patch for this. But one thing I want to ask is that whether we should keep default as stdout or as proposed in the ticket some dumpdata.json

comment:4 by ANUBHAV JOSHI, 10 years ago

I have yet to add tests.
https://github.com/coder9042/django/compare/ticket_22258?expand=1

Currently the option has been added but default is stdout.
I think that default should be as it is because there are times when data is not that big and people will like to see the result then and there itself, plus this way backward compatibility can be maintained.

Last edited 10 years ago by ANUBHAV JOSHI (previous) (diff)

comment:5 by ANUBHAV JOSHI, 10 years ago

comment:6 by loic84, 10 years ago

Add an option to specify a file name to write the output to (under the current working directory)

Why under the current working directory? open() does the right thing by default, if given a relative path, it'll use the current working directory. The current working directory could very much be readonly, and requiring people to cd to target a specific directory is not practical.

From a quick look at the patch, I think it does the right thing.

in reply to:  6 ; comment:7 by Gwildor Sok, 10 years ago

Replying to loic84:

Add an option to specify a file name to write the output to (under the current working directory)

Why under the current working directory? open() does the right thing by default, if given a relative path, it'll use the current working directory. The current working directory could very much be readonly, and requiring people to cd to target a specific directory is not practical.

From a quick look at the patch, I think it does the right thing.

I'm sorry, this was what I meant. So you can also do -o ../dumps/dump.json, or something alike. Patch indeed looks good on that matter.

About the default: I agree that defaulting to stdout is the way to go to maintain backwards compatibility. The main reason I opted for generating a filename and using that when not specific, is in the light of ticket #22258.

comment:8 by ANUBHAV JOSHI, 10 years ago

Has patch: set

in reply to:  8 comment:9 by ANUBHAV JOSHI, 10 years ago

Setting has patch

Last edited 10 years ago by ANUBHAV JOSHI (previous) (diff)

in reply to:  7 ; comment:10 by ANUBHAV JOSHI, 10 years ago

Replying to Gwildor:

About the default: I agree that defaulting to stdout is the way to go to maintain backwards compatibility. The main reason I opted for generating a filename and using that when not specific, is in the light of ticket #22258.

Do you have any ideas in mind. If yes then please comment them out on #22258 itself. I want to know exactly what you are suggesting.
You want progress to be displayed.Fine, but it would be nice to have some elaborations.

Also as in #22251, by russellm:"we're limited by the progress reporting tools of the underlying serialisation frameworks. If you've got any ideas on how this can be achieved, I'd love to hear them."

Last edited 10 years ago by ANUBHAV JOSHI (previous) (diff)

in reply to:  10 comment:11 by ANUBHAV JOSHI, 10 years ago

I think we can keep default as stdout and and for #22258, we can do the following:

  • When -o is not used, let the data be printed to stdout, as the data is printing people can see it and I don't think any progress display is required there. Also people may not want to open a file everytime they perform dumpdata even for small databases. If its large they'll use -o.
  • When -o will be used, then we can display progress percentage or something like that.

backwards compatibilty is there, also issue in #22258 is also addressed.
thoughts?

Last edited 10 years ago by ANUBHAV JOSHI (previous) (diff)

comment:12 by Russell Keith-Magee, 10 years ago

If you're outputting to console, I don't see how you can display a progress indicator. Making a progress indicator dependent on the use of -o seems like a reasonable approach to me.

comment:13 by Marc Tamlyn, 10 years ago

Triage Stage: AcceptedReady for checkin

comment:14 by Marc Tamlyn, 10 years ago

Patch needs improvement: set
Triage Stage: Ready for checkinAccepted

comment:15 by Anubhav Joshi <anubhav9042@…>, 10 years ago

Resolution: fixed
Status: assignedclosed

In f34e8fc890d44f4f913fe812f2cdeb5666f0fa27:

Fixed #22257 -- Added file output option to dumpdata command.

comment:16 by Marc Tamlyn <marc.tamlyn@…>, 10 years ago

In 09ab447d083558c0822acd58ab621e06c206ccba:

Merge pull request #2465 from coder9042/ticket_22258

Fixed #22257 -- Added file output option to dumpdata command.

comment:17 by Tim Graham <timograham@…>, 10 years ago

In e3c4205b79cff2be809c3698df2e9d53303b5070:

flake8 and doc fixes for refs #22257.

in reply to:  17 comment:18 by ANUBHAV JOSHI, 10 years ago

Thanks for that.

comment:19 by Gwildor Sok, 10 years ago

Thanks everyone for the quick implementation :)

Note: See TracTickets for help on using tickets.
Back to Top