You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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.
The text was updated successfully, but these errors were encountered: