-
Notifications
You must be signed in to change notification settings - Fork 399
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
Import issues #1197
Comments
I doubt the fix to #1116 is to blame.... |
But I'm guessing something to do with differing plane ids locally..?
If I truncate the table, then reimport... They all come in empty... |
Caused by 2d82511 as the plane id ( |
I notice that |
@reedy, I've looked into this today and I don't think this is a bug. The export/backup functionality will export the database IDs for multiple entities:
When present in the upload payload, this allows the import code to easily match entities even if they were renamed or otherwise updated between the backup creation and upload. Importantly, during parsing, these take priority over the string columns (e.g.
However, The solution is to wipe the The data files have not been updated in a while (7 years for Footnotes
|
See my comment on 992 - #992 (comment) Users are allowed to enter their own plane designations so I’m curious as to how this might play out here as well. They may or may not confirm to existing ids, even if there were an Id column. |
It doesn't change the situation much here. I only mentioned the OIDs matching as an explanation for why this only happened to planes. You should wipe all the OIDs when moving backups across database instances. For a local install, you have to clear that column (and the other OID columns as well). The import process will automatically create new entities for you if it can't match them based on the name. |
I note after deleting the databases, the updated imports etc.. Then importing my latest backup from openflights.org, the planes are wrong or mostly missing |
You need to delete the OIDs from the CSV when importing across instances to get the new instance to create whatever is not present in the database - try it. This only affects people moving data across instances. |
Aha, thanks. I wonder if this should almost be a difference between "backup" and "export"... Probably should be documented somewhere (on the site) too |
I think exporting them is correct because the names can (and do, even if infrequently) change while the IDs are stable. This helps if your backup is not recent. I think this is WAD. Let's be honest, either you're using openflights.org or you're running your own instance. I think this is only an issue for us. :)
I'm not sure about the site itself since I don't believe this applies to users of openflights.org. How about the repo docs? You're probably going to read these if you're running your own instance. |
On my dev install... I deleted all my flights (using the UI) and then imported a newer backup from openflights.org
It seems to have resulted in some weird plane type attributions, even though the exported CSV looks good
Should this be showing IDs or types?
The text was updated successfully, but these errors were encountered: