cube-js/cube

Variable Length Decimal Support to Handle Cube Store Parquet Data Type Issues

Open

#3 412 ouverte le 10 sept. 2021

Voir sur GitHub
 (1 commentaire) (0 réactions) (0 assignés)Rust (1 965 forks)batch import
cube storehelp wanted

Métriques du dépôt

Stars
 (19 563 stars)
Métriques de merge PR
 (Merge moyen 5j 16h) (138 PRs mergées en 30 j)

Description

Describe the bug When leveraging a MySQL decimal field that is defined as DECIMAL(65,30), the pre-aggregated results cannot be stored within Cube Store.

To Reproduce Steps to reproduce the behavior:

  1. Create a MySQL table (likely any database will do as its a Parquet conversion issue) with DECIMAL(65,30).
  2. Insert extremely large values in this field.
  3. Perform an aggregate query using SUM
  4. Define as a pre-aggregate query
  5. Watch the CREATE TABLE process fail when using Cube Store as your pre-aggregate data store repository.

Expected behavior

  1. Ideal behavior - Cube Store can correctly map data types of this nature.
  2. Acceptable behavior - Variable length can be defined as part of your measurement definition for pre-aggregate consumption

Screenshots N/A

Version: Current

Additional context None

Guide contributeur

Direction de recherche
Étudiez la logique de conversion Parquet de Cube Store dans la crate `cube store`, en particulier la gestion des types Decimal. Examinez le module `parquet` et les fonctions de mappage des types de données. Le problème mentionne un problème de conversion Parquet avec DECIMAL(65,30) depuis MySQL. Il n'y a qu'un seul commentaire, aucune PR liée. Envisagez d'ajouter la prise en charge des décimales à longueur variable ou de mapper vers un type Parquet approprié. Passez en revue les problèmes connexes ou les modifications de code dans le dépôt pour des correctifs similaires dans la gestion des Decimal.
Stack technique
rust
Domaine
backenddatabase
Type d'issue
Bug
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
2
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-3 heures
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Investigation requise
Prérequis
SQL
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
50