@yevgenypats I think we need to carefully consider whether to default to text here--it can result in changed behaviour whenever the SDK adds a new type. For example, intervals were previously stored as int, so if we defaulted to text without explicitly handling it in this plugin, then those would have silently started to convert to text. I'd rather have it fail very loudly when we upgrade the SDK to a version that added a new type, so it forces you to add support or fall back to the right thing.

Maybe a solution is to add a test that iterates over all types in the SDK, checking they are all handled? Then you wouldn't be able to upgrade the SDK to a version with a new type without also updating the handled types.

@yevgenypats I think we need to carefully consider whether to default to text here--it can result in changed behaviour whenever the SDK adds a new type. For example, intervals were previously stored as int, so if we defaulted to text without explicitly handling it in this plugin, then those would have silently started to convert to text. I'd rather have it fail very loudly when we upgrade the SDK to a version that added a new type, so it forces you to add support or fall back to the right thing.

Maybe a solution is to add a test that iterates over all types in the SDK, checking they are all handled? Then you wouldn't be able to upgrade the SDK to a version with a new type without also updating the handled types.

Maybe we can have an option then. because let's say a community plugin is not up to date, it will be pretty hard requirement always staying up to date with all latest fields. maybe we can ignore this column as well? I think let's wait and see what issues this will cause.