Skip to content
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

Snowflake Connectivity #9435

Merged
merged 25 commits into from
Mar 20, 2024
Merged

Snowflake Connectivity #9435

merged 25 commits into from
Mar 20, 2024

Conversation

jdunkerley
Copy link
Member

@jdunkerley jdunkerley commented Mar 14, 2024

Pull Request Description

  • Initial connection to Snowflake via an account, username and password.
  • Move make_column_fetcher to the Type_Mapping types.
  • Move the JDBC common stuff to Entity_Naming_Properties type.
  • Add database selector and read_single_column to Connection.
  • Tweaks to Postgres_Dialect to allow it to stand in for Snowflake_Dialect (temporary).
  • Added Standard.Snowflake library.
  • Snowflake_Connection has all the methods working.
  • Ability to read all primitives working (Timestamp with TimeZone untested at present).
  • Note: Snowflake_Spec not currently used as needs dialect fixes first.

image

image

Uploading image.png…

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

  • The documentation has been updated, if necessary.
  • Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
  • All code follows the
    Scala,
    Java,
    and
    Rust
    style guides. In case you are using a language not listed above, follow the Rust style guide.
  • All code has been tested:
    • Unit tests have been written where possible.
    • If GUI codebase was changed, the GUI was tested when built using ./run ide build.

@jdunkerley jdunkerley added the CI: Clean build required CI runners will be cleaned before and after this PR is built. label Mar 15, 2024
Move some responsibilities to Type_Mapping.
…nnection.enso

Co-authored-by: Radosław Waśko <radoslaw.wasko@enso.org>
Based off Postgres for now.
snowflake : Postgres_Dialect
snowflake =
Postgres_Dialect.Value make_internal_generator_dialect "Snowflake" "Snowflake_Dialect" Snowflake_Type_Mapping
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok for the PoC although in later iterations I'd consider adding some layer of abstraction - maybe we could define Postgres_Like_Dialect and have both Snowflake_Dialect and Postgres_Dialect "inherit" from it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think for next pass will just be a copy spun off from the Postgres_Dialect.
Eventually I'd like to have an Ansi_SQL_Like_Dialect but I dont have enough of a feel how best to do it yet.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it feels like we are lacking some good primitive for abstraction in Enso that would allow us to define the default behaviours on a variety of functions, but then override some of them for some of the dialects, while ideally still being able to delegate to the default from within an override under some conditions.

Essentially, regular Java-like class inheritance seems like a simplest abstraction, but we don't have that.

@JaroslavTulach maybe you have some ideas how we could achieve that from the perspective of designing a good internal API? We'd want to avoid having to write a ton of boilerplate code just to inherit the default behaviour.

Currently my 'best approximation' is the File_Write_Strategy which gives us defaults and then allows to override them by specifying custom functions. But with only ~5 methods it already is ugly and not too readable because all methods must be defined on a single line (as fields of the Value constructor) and it already introduces boilerplate. I don't feel like this approach would scale well to the complexity that Dialects have. But I don't yet know of anything that would work better either.

Enso
Copyright 2020 - 2024 New Byte Order sp. z o. o.

'snowflake-jdbc', licensed under the The Apache Software License, Version 2.0, is distributed with the Snowflake.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not related to this PR directly but I'm thinking if we should add a 'display name' for our components in the license review tool, as it would look much better if it were:

Suggested change
'snowflake-jdbc', licensed under the The Apache Software License, Version 2.0, is distributed with the Snowflake.
'snowflake-jdbc', licensed under the The Apache Software License, Version 2.0, is distributed with the Standard.Snowflake library.

build.sbt Outdated Show resolved Hide resolved
Copy link
Member

@radeusgd radeusgd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like a great prototype for quickly getting Snowflake integrated.

I have a few issues (noted above) that I think need addressing, but I think it's fine to do them as a separate PR to be able to already benefit from the integration. The most important ones IMO are:

  1. figuring out the type mapping to behave nicely with columns that report a small numeric type but still contain larger values,
  2. refactoring the Postgres_Dialect to avoid snowflake specific if's inside of it, if possible. I'm not yet sure how to do this in the best way given that we don't have proper inheritance...

@jdunkerley jdunkerley added the CI: Ready to merge This PR is eligible for automatic merge label Mar 19, 2024
@jdunkerley jdunkerley added the CI: Keep up to date Automatically update this PR to the latest develop. label Mar 20, 2024
@jdunkerley jdunkerley removed the CI: Keep up to date Automatically update this PR to the latest develop. label Mar 20, 2024
Copy link
Member

@JaroslavTulach JaroslavTulach left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest using private a bit more.

@@ -0,0 +1,12 @@
from Standard.Base import all
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this module be marked private?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes will make the dialect private when I restructure it in next PR.

@@ -0,0 +1,182 @@
private
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

- warehouse: The name of the warehouse to use.
Snowflake account:Text credentials:Credentials database:Text="SNOWFLAKE" schema:Text="PUBLIC" warehouse:Text=""

## PRIVATE
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest to move these ## PRIVATE methods to another private module and make them extension methods.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The methods on the details class make the Database.connect method work so need to be attached to the type.

@@ -12,6 +12,17 @@
import org.enso.polyglot.common_utils.Core_Date_Utils;

public class JDBCUtils {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing private constructor. The default constructor is public hence people could create instances of this utility methods only class, which makes little sense.

@@ -0,0 +1,298 @@
from Standard.Base import all
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess only Snowflake_Details need to be visible from other modules. If so, I suggest to make this module private.


connection self = self.data.at 0
tinfo self = self.data.at 1
t self = self.data.at 2
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do recognize the group laziness pattern. Nice.

@jdunkerley jdunkerley merged commit 2f0d99a into develop Mar 20, 2024
38 of 41 checks passed
@jdunkerley jdunkerley deleted the wip/jd/table-fixes branch March 20, 2024 10:06
@mwu-tow mwu-tow mentioned this pull request Mar 20, 2024
5 tasks
mergify bot pushed a commit that referenced this pull request Mar 21, 2024
The #9435 broke the notarization, as it adds new binaries to the package that need to be included in our code signing workarounds.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI: Clean build required CI runners will be cleaned before and after this PR is built. CI: Ready to merge This PR is eligible for automatic merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants