Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

new data import|export beta tree commands #2738

Open
mshanemc opened this issue Feb 21, 2024 · 2 comments
Open

new data import|export beta tree commands #2738

mshanemc opened this issue Feb 21, 2024 · 2 comments
Labels
announcement Announcement to the community

Comments

@mshanemc
Copy link
Contributor

mshanemc commented Feb 21, 2024

There's been a number of longstanding problems and limitations with the tree commands whose fixes required a rewrite. There's a few small breaking changes and y'all run these commands A LOT so we're releasing them through our normal beta process.

Phase 1: Beta (now)

  1. introduce data import beta tree and data export beta tree
  2. existing commands encourage users to try the new ones

Breaking changes between existing commands and the beta commands

  1. import beta removes the hidden, deprecated content-type. Only json files are supported. Usage: ~5 per year.
  2. import beta removes the --config-help flag. The schema information is now in the command help. Usage: ~1 per week.

Other changes

  1. export --plan writes Object names as the file name. It used to append an s on the end. So the filename is now Account.json and Foo__c.json instead of Accounts.json and Foo__cs.json. Since the filenames are part of the plan file, this only affects newly generated plans/files.
  2. export beta no longer writes empty child objects. Previously, you'd see properties with {records: []} that had no effect on imports.
  3. import beta ignores the resolveRefs and saveRefs (export beta produces them to preserve compatibility with the non-beta import command).
  4. export beta now handles more than 2 levels of child objects in a query using --plan (up to 5 because that's SOQL's limit). see Extract deeply nested (more than 1 level) plan #2663 and Extract deeply nested (more than 1 level) plan #2359
  5. both export beta and import beta with --plan handle records that refer to records of the same object type (ex: Account with ParentId, User with ManagerId). Improve handling of self-referencing lookups by force:data:tree commands #2364
  6. import beta using --plan handles files with more than 200 records. It will batch them into groups of 200 per object.
  7. import supported plan files where the files property could contain objects (the export command did not produce such files). For import beta only strings are allowed and will throw an error otherwise.
  8. import beta in --files mode (not --plan) will import the files in parallel (files can't reference each other without --plan)
  9. import provides deprecation warnings for both content-type and config-help flags, since import beta removes them. --config-help is now hidden (content-type was already hidden)
  10. import beta with --plan is optimized for references (using the saved ID of one record as the value of a Relationship Field in another) that follow the standard pattern @[ObjectName]Ref[SomeNumber], like @AccountRef54 or @Foo__cRef0. In the past, a ref could start with @ followed by anything. The export command historically produced refs in the preferred format (as does export beta), but you may have handcrafted your own at some point. Some of the enhancements (self-referential objects, support for more than 200 records in a file, etc) required the preferred pattern.

Export files created by export beta are compatible with import and import beta

The new record limit for import beta with --plan is not documented. You're most likely to hit a call stack depth (from recursion) or some org limit (data storage, api call limits) depending on your data and your org. If you're doing something really large, we still recommend the bulk commands.

During the beta, please submit issues with the new commands to https://github.com/forcedotcom/cli/issues

In general, you'll find the --plan options much more powerful. We encourage you to use those over the --files option.

Phase 2: GA the new commands, put the old under legacy. [July 10 2024]

  1. the old commands will be renamed to data import legacy tree and data export legacy tree, and marked hidden and deprecated with the Phase 3 date
  2. the new commands will become data import tree and data export tree. They will still work with their beta alias, but you'll get a deprecation warning if you use it.
  3. the force: aliases will go to the new commands
  4. data export tree with --json will being warning that it will change json output (the saveRefs/resolveRefs properties are in the json output) after Phase 3 date

Phase 3: retire the legacy commands and all their dependent code [Nov 10 2024]

  1. make export stop writing the unused saveRefs and resolveRefs properties on plan files, and stop returning them in json
  2. tighten schema to remove the object part of files, and remove saveRefs and resolveRefs
  3. remove the beta alias from import|export
@mshanemc mshanemc added the announcement Announcement to the community label Feb 21, 2024
@mshanemc mshanemc pinned this issue Feb 21, 2024
@RemiLeGuin
Copy link

Hello @mshanemc,
Thank you for this new release! I particularly like to query more than 2 levels of child object, the import of more than 200 records and the possibility to refer to the same object type in a relation.
Do you have any plan to support record type definition at import?

@mshanemc
Copy link
Contributor Author

mshanemc commented Mar 5, 2024

Hello @mshanemc, Thank you for this new release! I particularly like to query more than 2 levels of child object, the import of more than 200 records and the possibility to refer to the same object type in a relation. Do you have any plan to support record type definition at import?

Nobody's asked for that before. You can open a request for it https://github.com/forcedotcom/cli/discussions (that's what we use to prioritize what gets done next). It's a good feature idea but probably needs some design discussions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
announcement Announcement to the community
Projects
None yet
Development

No branches or pull requests

2 participants