Personnalisation des procédures stockées et des gestionnaires (handlers)¶

Personnalisation des procédures à un niveau élevé¶

Les procédures de haut niveau ne sont utilisées que comme point d’entrée dans la logique réelle mise en œuvre en Java. Ainsi, pour modifier la logique sous-jacente, un chemin vers le nouveau gestionnaire (handler) doit être spécifié lors de la recréation de la procédure stockée. Cette procédure doit être ajoutée en tant que code personnalisé dans le script setup.sql. Pour ce faire, il faut fournir la nouvelle implémentation Java, qui peut être réalisée à partir de zéro ou en utilisant les fournisseurs du SDK builders, qui sont décrits ci-dessous :

CREATE OR REPLACE PROCEDURE PUBLIC.CONFIGURE_CONNECTOR(input VARIANT)
    RETURNS VARIANT
    LANGUAGE JAVA
    RUNTIME_VERSION = '11'
    PACKAGES = ('com.snowflake:snowpark:1.11.0')
    IMPORTS = ('/jar_with_custom_code.jar')
    HANDLER = 'com.custom.handler.CustomHandler.configure';

Personnalisation des procédures de portée réduite¶

Certaines des procédures fournies par le Snowflake Native SDK for Connectors ont si peu de logique qu’elles peuvent être facilement rédigées en utilisant uniquement SQL. Pour ces procédures, il est possible de remplacer les implémentations par défaut en utilisant uniquement SQL. Par exemple, certaines procédures avec les suffixes _VALIDATE ou _INTERNAL peuvent être réimplémentées de cette manière. Toutes ces procédures peuvent également être personnalisées en utilisant l’approche Java uniquement via Builders. Cette approche est expliquée ci-dessous. Il est également possible de remplacer une procédure qui n’utilisait que SQL par un gestionnaire (handler). Dans ce cas, elle sera la même que pour les procédures stockées de haut niveau ci-dessus.

CREATE OR REPLACE PROCEDURE PUBLIC.CONFIGURE_CONNECTOR_INTERNAL(config VARIANT)
    RETURNS VARIANT
    LANGUAGE SQL
    EXECUTE AS OWNER
    AS
    BEGIN
        -- input some custom logic here
        RETURN OBJECT_CONSTRUCT('response_code', 'OK');
    END;

Constructeurs¶

Pour conserver le flux défini par SDKdans le connecteur lors de la personnalisation, des objets de helper appelés builders sont fournis. Chaque classe de handler a son propre builder regroupé. Ceux-ci permettent à l’utilisateur de fournir une implémentation personnalisée des objets Java sous-jacents. Ainsi, le développeur n’a pas besoin de toucher au flux interne du connecteur et peut se concentrer sur la personnalisation des parties nécessaires. Il y a un petit problème lorsque vous utilisez builders, cette approche nécessite également que le développeur spécifie la nouvelle méthode de point d’entrée qui sera référencée dans la procédure stockée.

Par exemple, un handler utilisant un validator personnalisé utilisant le builder ressemble à ceci :

class CustomConnectionConfigurationInputValidator implements ConnectionConfigurationInputValidator {
    @Override
    public ConnectorResponse validate(Variant config) {
        // CUSTOM LOGIC
        return ConnectorResponse.success();
    }
}

class CustomHandler {

    // Path to this method needs to be specified in the PUBLIC.SET_CONNECTION_CONFIGURATION procedure using SQL
    public static Variant configureConnection(Session session, Variant configuration) {
            //Using builder
        var handler = ConnectionConfigurationHandler.builder(session)
            .withInputValidator(new CustomConnectionConfigurationInputValidator())
            .build();
        return handler.connectionConfiguration(configuration).toVariant();
    }
}

La méthode du point d’entrée dans SQL doit alors être spécifiée comme suit :

CREATE OR REPLACE PROCEDURE PUBLIC.SET_CONNECTION_CONFIGURATION(input VARIANT)
    RETURNS VARIANT
    LANGUAGE JAVA
    RUNTIME_VERSION = '11'
    PACKAGES = ('com.snowflake:snowpark:1.11.0')
    IMPORTS = ('/jar_with_custom_code.jar')
    HANDLER = 'com.custom.handler.CustomHandler.configureConnection';