Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#22257 closed New feature (fixed)

Write to specified file for dumpdata

Reported by: Gwildor Owned by: anubhav9042
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 2 years ago by aaugustin

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

Yes, that makes sense.

comment:2 Changed 2 years ago by anubhav9042

  • Cc anubhav9042@… added
  • Owner changed from nobody to anubhav9042
  • Status changed from new to assigned

comment:3 Changed 2 years ago by anubhav9042

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 2 years ago by anubhav9042

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 2 years ago by anubhav9042 (previous) (next) (diff)

comment:5 Changed 2 years ago by anubhav9042

comment:6 follow-up: Changed 2 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 ; follow-up: Changed 2 years ago by Gwildor

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 follow-up: Changed 2 years ago by anubhav9042

  • Has patch set

comment:9 in reply to: ↑ 8 Changed 2 years ago by anubhav9042

Setting has patch

Last edited 2 years ago by anubhav9042 (previous) (diff)

comment:10 in reply to: ↑ 7 ; follow-up: Changed 2 years ago by anubhav9042

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 2 years ago by anubhav9042 (previous) (diff)

comment:11 in reply to: ↑ 10 Changed 2 years ago by anubhav9042

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 2 years ago by anubhav9042 (previous) (diff)

comment:12 Changed 2 years ago by russellm

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 2 years ago by mjtamlyn

  • Triage Stage changed from Accepted to Ready for checkin

comment:14 Changed 2 years ago by mjtamlyn

  • Patch needs improvement set
  • Triage Stage changed from Ready for checkin to Accepted

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

  • Resolution set to fixed
  • Status changed from assigned to closed

In f34e8fc890d44f4f913fe812f2cdeb5666f0fa27:

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

comment:16 Changed 2 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 follow-up: Changed 2 years ago by Tim Graham <timograham@…>

In e3c4205b79cff2be809c3698df2e9d53303b5070:

flake8 and doc fixes for refs #22257.

comment:18 in reply to: ↑ 17 Changed 2 years ago by anubhav9042

Thanks for that.

comment:19 Changed 2 years ago by Gwildor

Thanks everyone for the quick implementation :)

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