Conversation
This leads to an error when inferring metadata, as new datapackage adds a counter to second "tech" column, resulting in "tech2"
|
Thank you for you changes! Before going on vacation I'll not be able to review unfortunately. But if still needed I will do after (in KW29). |
| for fk in resource["schema"]["foreignKeys"] | ||
| if fk["reference"]["resource"] == "bus" | ||
| ] | ||
| datapackage_folder = path[:-17] # Remove "/datapackage.json" form path |
There was a problem hiding this comment.
Is this magic number always -17 ?
There was a problem hiding this comment.
You are right - I should probably look for "datapackage.json" and strip it.
|
@henhuy - do you know how to fix the tests? It seems it just cannot accept 0 = 0.0 |
It's really annoying. Locally, tests work. It's frustrating to compare LP files with such little diffs. |
3 participants
Description
I could fix error due to "fake" foreign keys by extracting them from schema before reading in the datapackage.
When facades are built, the extracted foreign keys pointing to sequences are re-added to foreign keys, so that sequences (profiles etc.) can be connected correctly.
This is a simple workaround, which leaves most code in place and should work out-of-the-box for older and newer environments.
A more general approach as discussed in #74 is favorable, but would break older datapackage and thus is a breaking change.
Had to fix some LP files where order of lines had changed and fix two datapackages where duplicate columns were present (which is handled differently in newer datapackage version).
Fixes #187
Type of change
Please tick or delete options that are not relevant.
Checklist:
Please tick or delete options that are not relevant.
pre-commithooks