Opened 3 years ago

Closed 3 years ago

Last modified 3 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: master
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 Changed 3 years ago by Aymeric Augustin

Triage Stage: UnreviewedAccepted

Yes, that makes sense.

comment:2 Changed 3 years ago by ANUBHAV JOSHI

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

comment:3 Changed 3 years ago by ANUBHAV JOSHI

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 Changed 3 years ago by ANUBHAV JOSHI

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

Version 1, edited 3 years ago by ANUBHAV JOSHI (previous) (next) (diff)

comment:5 Changed 3 years ago by ANUBHAV JOSHI

comment:6 Changed 3 years ago by 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.

comment:7 in reply to:  6 ; Changed 3 years ago by Gwildor Sok

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 Changed 3 years ago by ANUBHAV JOSHI

Has patch: set

comment:9 in reply to:  8 Changed 3 years ago by ANUBHAV JOSHI

Setting has patch

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

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

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 3 years ago by ANUBHAV JOSHI (previous) (diff)

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

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 3 years ago by ANUBHAV JOSHI (previous) (diff)

comment:12 Changed 3 years ago by Russell Keith-Magee

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 Changed 3 years ago by Marc Tamlyn

Triage Stage: AcceptedReady for checkin

comment:14 Changed 3 years ago by Marc Tamlyn

Patch needs improvement: set
Triage Stage: Ready for checkinAccepted

comment:15 Changed 3 years ago by Anubhav Joshi <anubhav9042@…>

Resolution: fixed
Status: assignedclosed

In f34e8fc890d44f4f913fe812f2cdeb5666f0fa27:

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

comment:16 Changed 3 years ago by Marc Tamlyn <marc.tamlyn@…>

In 09ab447d083558c0822acd58ab621e06c206ccba:

Merge pull request #2465 from coder9042/ticket_22258

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

comment:17 Changed 3 years ago by Tim Graham <timograham@…>

In e3c4205b79cff2be809c3698df2e9d53303b5070:

flake8 and doc fixes for refs #22257.

comment:18 in reply to:  17 Changed 3 years ago by ANUBHAV JOSHI

Thanks for that.

comment:19 Changed 3 years ago by Gwildor Sok

Thanks everyone for the quick implementation :)

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