Erreur : valeur/clé primaire non unique (ou sql_distinct_key), débordement de valeur ou collision lors du calcul de la somme

Cette page vous aidera à résoudre cette erreur Looker : 

  Non-unique value/primary key (or sql_distinct_key), value overflow or collision when computing sum

Cette erreur peut être due à l'un des problèmes suivants :

Clé primaire non unique

La cause la plus courante de cette erreur est que votre requête implique une clé primaire non unique. Pour spécifier une clé primaire, utilisez primary_key: yes sur une dimension, qui doit être une dimension sans valeurs répétées.

Solution rapide

Une fois que vous avez identifié les dimensions de clé primaire dans votre requête, vous pouvez vérifier leur unicité dans l'exécuteur SQL de Looker avec cette requête : 

SELECT
  COUNT(*),
  COUNT(DISTINCT your_primary_key)
FROM
  your_table_name

Si les totaux de cette requête correspondent, la clé primaire est unique. Si les décomptes ne correspondent pas, la clé primaire n'est pas unique et apparaît sur plusieurs lignes. Vous devez choisir ou créer une dimension comme clé primaire. Si aucune dimension ne contient de valeurs entièrement uniques, vous devrez peut-être concaténer des champs pour créer votre propre dimension de clé primaire.

Utiliser row_number pour générer une clé primaire pour une table dérivée

Si ce message d'erreur s'affiche avec une table dérivée, vous pouvez utiliser la fonction de fenêtre row_number() dans les bases de données Postgres et Redshift pour créer un champ unique. Ce champ peut alors servir de clé primaire: 

  view: derived_table_name {
    derived_table {
      sql:
      SELECT
      row_number() OVER(ORDER BY created_at) AS prim_key,
      *
      FROM orders ;;
    }

    dimension: prim_key {
      type: number
      primary_key: yes
      sql: ${TABLE}.prim_key ;;
    }
  }

Dans MySQL, vous pouvez utiliser une variable qui itère chaque ligne pour obtenir le même effet: 

  view: derived_table_name {
    derived_table {
     sql:
      SELECT
      CAST(@rownum := @rownum + 1 AS UNSIGNED) AS prim_key, t.*
      FROM orders t,
      (SELECT @rownum := 0) r ;;
    }

    dimension: prim_key {
      type: number
      primary_key: yes
      sql: ${TABLE}.prim_key ;;
    }
  }

Utilisation incorrecte de sql_distinct_key

Si l'une des mesures de votre requête est de type sum_distinct, il est possible qu'il existe une incohérence d'unicité entre les paramètres sql_distinct_key et sql de cette mesure.

Solution rapide

Consultez la page de documentation de sum_distinct pour en savoir plus sur ces paramètres. exigences.

Référencer des champs dans les vues avec des fanouts

Votre requête peut utiliser une mesure de la vue A, mais cette mesure fait référence à un champ de la vue B. Dans ce cas, Looker utilisera la clé primaire de la vue A pour calculer cette mesure. Si votre requête implique une distribution ramifiée, ce n'est peut-être pas la clé primaire correcte à utiliser. (Pour en savoir plus sur les fanouts, consultez notre post destiné à la communauté.)

Solution rapide

Pour résoudre ce problème, ajoutez la clé primaire de la vue B à la mesure du problème avec le paramètre sql_distinct_key.

Que se passe-t-il si aucune des causes listées ne s'applique, mais que l'erreur se produit toujours ?

Il existe une situation très spécifique dans laquelle votre clé primaire peut être unique, et les autres causes de ce problème ne s'appliquent pas à votre requête, mais cette erreur se produit quand même. Tout d'abord, votre requête impliquera plusieurs jointures de relationship: one_to_many. Deuxièmement, l'une des mesures de votre requête fait référence à une dimension qui combine les valeurs de plusieurs vues jointes.

Pour résoudre ce problème, notez cette mesure, puis procédez comme suit :

  1. Recherchez la dimension dans la mesure qui combine les valeurs de plusieurs vues jointes.
  2. Recherchez les vues référencées par cette dimension.
  3. Concaténez les clés primaires de ces vues à l'aide de la fonction de concaténation de votre dialecte SQL.
  4. Placez cette clé concaténée dans un paramètre sql_distinct_key sur la mesure à l'origine du problème.