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
This section of code prefixes any MySQL reserved words like 'condition' so that it becomes '_condition'
This is even more apparent when switching from the Chunk importer to the MySQL importer because it causes data properties to change.
MySQL importer results on left, Chunk Importer results on right
There is a note in the code that this can be dropped once Drupal 9 goes away.
Detailed Feature Description
Clean up queries to use []. https://www.drupal.org/node/2986894 so that this prefixing of certain properties can be dropped.
This however would be a breaking change for any consumers of the API.... so I don't know how to reconcile that, unless it is an option that defaults to the prefixes way?
Problem and Motivation
Ideally we don't want DKAN to be opinionated about what data column names / properties are. We want properties to be driven by the datasource.
Potential Benefits
Users will not have data shifts if they switch from the Chunk importer to MySQL importer, or vice versa.
DKAN will not introduce changes to data properties
Put the ability in the UI to opt out of the prefixing. That way individual sites can decide whether they want to make a breaking change for their data consumers.
Additional Context
This came up for CMS:PDC
The text was updated successfully, but these errors were encountered:
Feature Description
This section of code prefixes any MySQL reserved words like 'condition' so that it becomes '_condition'
This is even more apparent when switching from the Chunk importer to the MySQL importer because it causes data properties to change.
MySQL importer results on left, Chunk Importer results on right
There is a note in the code that this can be dropped once Drupal 9 goes away.
Detailed Feature Description
Clean up queries to use []. https://www.drupal.org/node/2986894 so that this prefixing of certain properties can be dropped.
This however would be a breaking change for any consumers of the API.... so I don't know how to reconcile that, unless it is an option that defaults to the prefixes way?
Problem and Motivation
Ideally we don't want DKAN to be opinionated about what data column names / properties are. We want properties to be driven by the datasource.
Potential Benefits
Users will not have data shifts if they switch from the Chunk importer to MySQL importer, or vice versa.
DKAN will not introduce changes to data properties
Target Audience
Possible Implementation
Additional Context
This came up for CMS:PDC
The text was updated successfully, but these errors were encountered: