Add a dialect.type property
#1055
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Deploying datapackage with
|
| Latest commit: |
76c0a8e
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://c5f61e8a.datapackage-6gp.pages.dev |
| Branch Preview URL: | https://921-dialect-type.datapackage-6gp.pages.dev |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
dialect.typefield #921The proposal is authored by @khusmann and has been migrated from frictionlessdata/datapackage-v2-draft#82. It was also not possible to migrate some suggestions mostly authored by @ezwelty so we need to be aware that some context is still in the initial PR.
Here's another attempt at
dialect.type, rebased on Peter's new structure (see #74).dialect.typealso makes it possible to make different fields required for different dialect types. For example, for adatabasedialect type, does it make sense to havetablebe an optional property? With spreadsheets, there's at least the concept of the "first" spreadsheet that can be loaded by default -- but with databases, is there such thing as a "first" table? If not, I thinkdialect.tableshould be required for database dialect types.