-
Notifications
You must be signed in to change notification settings - Fork 428
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Adding support for orgaznization and account names when creating db f… #1114
feat: Adding support for orgaznization and account names when creating db f… #1114
Conversation
Just noticed this PR #1090 |
this looks fine, but its failing the check-docs test. its unclear why, just fails with exit code 2. could you please look into this and we can get this merged? |
@sfc-gh-swinkler - thanks for checking, I did correct that. FYI @gouline. |
@sfc-gh-swinkler Is the breaking change really warranted? At the very least Also |
@gouline - |
Deprecation means it will be removed eventually, my point is that it's unnecessary. If the I'd understand the deprecation if it was a new way that improves consistency. This does the opposite. |
But yeah I am fine with removing "deprecation" - as you said using |
Current
Maintaining two parallel ways of defining the same feature doesn't make much sense either. I'm sorry, this PR feels like duplication of an existing feature that enforces a preference without introducing/fixing anything that cannot already be done, while also introducing an inconsistent precedent (i.e. not using fully-qualified names like in |
I am inclined to agree with @gouline that supporting two different methods is not proper. However, I think it should be made more clear in the documentation that |
Allowes to create database from share using
organization_name.account_name
notation. Add deprecation warning when usingprovider
(based on this and this).Supports adding comments when creating a database from share (didn't work before).
Test Plan
References
resolves #1107