Issues for new contributors

[kokorin]

Thank you for the project!
I would like to help in development, unfortunately there are only 2 issues (as of now).
It could be useful having good-to-fix issues with novice or newcomer label. It would help me to help you.

[littleK0i]

Most bugs and issues related to changes in Snowflake behaviour are resolved in 0-2 days, so problems do not accumulate.

I would appreciate contributions related to the following fundamental topics (in order of priority):

1. Conversion from Terraform and other tools. We already have snowddl-convert command and some built-in converters, but it is very basic and not documented. I generally do not have access to less organised environments and can hardly relate to problems associated with that.

2. Iceberg tables. I find an entire Snowflake implementation of Iceberg tables problematic, but some people seems to have interest in it. If you have a real world use case, which includes refresh logic and transformations logic on top of data in Iceberg tables, please feel free to describe it and potentially contribute parser / resolver covering such use case.

3. Getting rid of "short hash". Some object types are marked with "Short hash" note in documentation. It means that instead of actually checking each individual object parameter we generate CREATE SQL, calculate short hash out of it and compare with existing short hash stored in comments. If sort hash is the same, SnowDDL assumes no changes are required. If new short hash is different, SnowDDL re-created an entire object. It would be nice to reduce reliance on short hash and use ALTER, if possible. The main problem here is covering all known edge cases with checks and tests. It might be difficult to do for some object types.

Thank you!

[MartinCairnsSQL]

A new feature which would be useful, is allowing array type placeholders.

I've got two Snowflake instances (Non-Prod & Prod) with different private networks and would like to use the placeholder to hold the array of network address ranges to apply directly to the network rule value_list.

At the moment the only work around is to create the network rules for both and assign network policies using the placeholders but having network rules which don't work on instance isn't good.

[littleK0i]

@MartinCairnsSQL , in theory, placeholders should work with lists when used purely.

For example, this should work:

rules: ${{my_fancy_rules}}

But not this:

rules: "abc ${{my_fancy_rules}} cde"

[littleK0i]

Ahh, parser does not allow complex types in JSON schema validation.

Hmm... let me check, maybe we can improve it a bit.

[littleK0i]

@MartinCairnsSQL , it is now possible to use lists as placeholder values since 0.36.0.

[MartinCairnsSQL]

@littleK0i I've updated my placeholders and the arrays are now working for lists of network rules.

Thanks