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

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset
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.
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 3 years ago by ANUBHAV JOSHI (previous) (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