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

[RFC] How to handle selected records in exports #7817

Open
doenietzomoeilijk opened this issue Oct 28, 2019 · 3 comments
Open

[RFC] How to handle selected records in exports #7817

doenietzomoeilijk opened this issue Oct 28, 2019 · 3 comments
Labels
keep RFC Request For Comments

Comments

@doenietzomoeilijk
Copy link

In #7812 I managed to fix the breaking error that occurred during exports. However, as it stands, exports still won't always work for all cases.

If your setup has a contenttype with a select field that pulls content from another contenttype, those values will be stored by ID by default. It's optional to use a different field for storage. That means this content might break during export-import, since those IDs might not stay the same.

The ways around this, as I see them:

  • Actually store the IDs in the export (and use them when importing, too

    Pro: makes the whole process more predictable and "safe"
    Con: Will bork things up when importing into a database when there's already content there.

  • On export, do a special song and dance for select content where the linking field is ID, and use that for the export data

    Pro: retain the functionality of importing into an existing database
    Con: hell of a lot more work and it feels a bit kludg-y to me

  • Just not support it and notify export users of this, giving them the hint to maybe use another field for the link if they are going to use export/import in the future

    Pro: least work of all the options, no changes to possibly already used workflows so no BC break for anyone
    Con: not user friendly

Personally I'm leaning towards the first option, but I'd like some input on the matter, or maybe some insight that I might've missed.

@bobdenotter
Copy link
Member

If we do a "backup" or "full export" from an SQL database, it also includes the ID's. Importing that as-is in an existing DB will break as well, if there's already content in there.

In that light, I think the "Actually store the IDs in the export" option is perfectly valid.. My vote is for that one.

@bobdenotter bobdenotter added the RFC Request For Comments label Oct 28, 2019
@doenietzomoeilijk
Copy link
Author

Right, and there's the "overwrite my stuff" flag anyway. Allright, that confirms my thinking.

@stale
Copy link

stale bot commented Dec 27, 2019

This issue has been automatically marked as stale because it has not had recent activity. Maybe this issue has been fixed in a recent release, or perhaps it is not affecting a lot of people?
It will be closed if no further activity occurs, because we like to keep the issue queue concise and actual.
If you think this issue is still relevant, please let us know. Especially if you’d like to help resolve the issue, either by helping us pinpointing the cause of a bug, or in implementing a fix or new feature.

@stale stale bot added the stale Stale issues & PRs flagged for closing label Dec 27, 2019
@stale stale bot removed the stale Stale issues & PRs flagged for closing label Dec 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
keep RFC Request For Comments
Projects
None yet
Development

No branches or pull requests

2 participants