Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[feature] DatasetT

Abierto
  • ¿Algo no está bien?
#704 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
scala, spark
Área
data

Línea de trabajo

Comienza revisando la API existente de TypedDataset y su integración con cats; después, compara la sintaxis propuesta F[TypedDataset[A]] con el wrapper DatasetT descrito en el issue. Se consideraría terminado cuando haya un diseño establecido y una API demostrablemente segura respecto a los tipos para la generación y manipulación de datasets a través de límites de lectura y escritura.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

feature

I'm reading about this library and think I'm going to use it in my next spark project. I'm really motivated by the ability to reduce needless runtime errors that should be detectable at compile time, and equally by wanting an ergonomic error channel for true runtime errors.

What i see gives me confidence that I can accomplish that using the cats integration with typed datasets. there's one thing that could make it a bunch more ergonomic: one of the biggest places i tend to get runtime errors is at the read-write boundary. say I'm trying to read a table that doesn't exist, or read/write where the schema on disk is incompatible with the one i expect. i can obviously handle this with the existing TypedDataset API after wrapping the IO boundaries in Sync[F].delay... but it would be nice to wrap not only Dataset manipulation but also the generation and subsequent manipulation in a type-safe DSL.

To that end two more-or-less isomorphic ideas come to mind. Both expect at a minimum evidence of Monad[F] (maybe only flatmap for the first one and TypedEncoder[A].

  1. additional syntax for F[TypedDataset[A]] that adds all the TypedDataset methods, also wrapped in F[_].

  2. an OptionT-like data class wrapping F[TypedDataset[A]]. Naming can be debated but for the sake of presentation, DatasetT. it has default constructor

def apply[F[_]: FlatMap: Ask[*[_], SparkSession], A:TypedEncoder](f: SparkSession => F[TypedDataset[A]])

and various syntactically or situationally preferable variations.

Have either of these patterns been considered? is there any reason they wouldn't make sense to adopt?

Assuming not, I'll try writing in a new project, and -- assuming it proves itself -- will create a PR.

Lenguaje dominante
Scala
Estrellas
897
Forks
135
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de typelevel/frameless

Todos los issues de typelevel/frameless

Issues similares

Más issues de Scala

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.