Opened 5 years ago

Closed 9 months ago

#11838 closed New feature (wontfix)

Make syncdb understand "initialdata" directory

Reported by: skorpan Owned by: bkonkle
Component: Core (Serialization) Version: master
Severity: Normal Keywords: syncdb loaddata initial_data
Cc: brandon.konkle@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

In many projects I often find the need to load my data from several separate JSON formatted data dumps. This is because it's easier to manage dumps from different models separately. Unfortunately, syncdb only understands one thing and that is a file named initial_data.json. I think it would be better if syncdb looked for that file, uses it if it finds it, otherwise looks for a directory named initialdata and loads all of the files from that directory.

Attachments (2)

ticket11838.diff (19.4 KB) - added by bkonkle 5 years ago.
ticket11838-2.diff (23.7 KB) - added by bkonkle 5 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 5 years ago by russellm

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

I can see the value in the idea, but I'd favor something more generic. Rather than making a special case of an 'initialdata' directory, make a directory a valid form for a fixture. That is, the loading sequence for ./manage.py loaddata foo would be something like:

  • foo.json, foo.yaml etc for each registered serializer
  • foo.json.gz, foo.yaml.gz etc (i.e., look for the compressed fixture
  • a directory named foo that may contain fixtures.

This would allow you to split your initial_data fixture over mutliple files as long as you called the fixture directory initial_data, but would also allow any other fixture to follow the same behavior.

comment:2 Changed 5 years ago by bkonkle

  • Owner changed from nobody to bkonkle
  • Status changed from new to assigned

Changed 5 years ago by bkonkle

comment:3 Changed 5 years ago by bkonkle

  • Has patch set

I've implemented the feature as Russel described above. My diff includes the changes to the code, tests, and documentation. Also, since this is my first Django contribution, I've added my name to the AUTHORS file. :-) Thanks!

comment:4 Changed 5 years ago by bkonkle

The patch is not applying correctly because of a bug in Macport's version of Subversion. I am removing the Macports-installed Subversion and compiling it from source. I'll re-submit the diff when I'm done.

Changed 5 years ago by bkonkle

comment:5 Changed 5 years ago by bkonkle

I've added a revised patch here with the line numbers referenced correctly. Thanks for nothing, Macports! :-)

comment:6 Changed 5 years ago by bkonkle

  • Cc brandon.konkle@… added

comment:7 Changed 5 years ago by russellm

  • Component changed from Uncategorized to Serialization
  • milestone 1.2 deleted

comment:8 Changed 4 years ago by SmileyChris

  • Severity set to Normal
  • Type set to New feature

comment:9 Changed 4 years ago by julien

  • Patch needs improvement set

The tests would need to be rewritten using unittests since this is now Django's preferred way.

comment:10 Changed 3 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:11 Changed 3 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:12 Changed 9 months ago by aaugustin

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

The new migrations framework doesn't load initial data any more.

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