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

A column copied by a foreign key loses the parent's core type (int32 becomes int)

Abierto
  • ¿Algo no está bien?
#1,578 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@dimitri-yatsenko ya está trabajando en esto.

Desde el 9/10/2026.

  • #1579 de @dimitri-yatsenko — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
Medio día
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
mysql, postgresql, python
Área
database

Línea de trabajo

Start with Attribute.sql_comment in heading.py, then follow compile_foreign_key and the PostgreSQL path through format_column_definition and column_comments, plus JobsTable's use of original_type. Run the reproduction script to confirm original_type is None on the child. Done means copied columns keep their :int32:-style marker and PostgreSQL emits COMMENT ON COLUMN for them. PR #1579 is already open against this issue, so check it before starting.

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

Descripción

Summary

A column copied into a child table by a foreign key loses the parent's core type. The parent's subject_id : int32 is stored with the comment marker :int32:, which Heading reads back as original_type; the child's copy of the column is created without the marker, so the child's heading reports the native SQL type (int) and original_type is None. Every table built from the child inherits the loss, which is most visible in jobs tables: creating one for an auto-populated table logs a portability warning for each inherited key attribute, about "native types" the user never declared.

On PostgreSQL the copied column loses its comment entirely (marker and text), because the comment is passed inline to a backend that sets comments with COMMENT ON COLUMN, and the copied columns are not among those it comments.

Reproduction

DataJoint 2.3.5.dev2 (master), MySQL 8.0:

import datajoint as dj

schema = dj.Schema("scratch_fk_core_types")

@schema
class Subject(dj.Manual):
    definition = """
    subject_id : int32
    """

@schema
class Session(dj.Manual):
    definition = """
    -> Subject
    session_idx : int16
    """

@schema
class Summary(dj.Computed):
    definition = """
    -> Session
    ---
    n : int32
    """

    def make(self, key):
        self.insert1(dict(key, n=1))

for t in (Subject, Session, Summary):
    print(t.__name__, {a: t.heading[a].original_type for a in t.heading.primary_key})
Summary.jobs  # creates the jobs table

Output:

Subject {'subject_id': 'int32'}
Session {'subject_id': None, 'session_idx': 'int16'}
Summary {'subject_id': None, 'session_idx': None}
[WARNING]: Native type 'int' is used in attribute 'subject_id'. Consider using a core DataJoint type for better portability.
[WARNING]: Native type 'smallint' is used in attribute 'session_idx'. Consider using a core DataJoint type for better portability.

The column comments in information_schema.columns confirm it: subject.subject_id is :int32:, while session.subject_id, summary.subject_id and summary.session_idx are empty.

Cause

  • Attribute.sql_comment (heading.py), which compile_foreign_key uses for the copied column's comment, re-adds only the :uuid: marker. Heading parsing has already moved every other core type out of the comment into original_type, so int32, int16, float64, varchar(n), date, and the rest are dropped.
  • On PostgreSQL, compile_foreign_key passes the comment to format_column_definition, which ignores inline comments on that backend; the copied column is never added to the COMMENT ON COLUMN statements that declare() (and alter()) run afterwards.
  • JobsTable builds its key from attr.original_type or attr.type; with original_type lost on inherited attributes, it falls back to the SQL type and declaration warns.

Impact

  • Child headings report native SQL types for inherited key attributes (describe() and anything reading original_type).
  • A spurious "Native type" warning per inherited key attribute whenever a jobs table is created, for nearly every auto-populated table.
  • On PostgreSQL, inherited columns also lose the parent's comment text.

Tables declared before a fix keep their stored comments; the fix applies to tables declared after it.

Proposed fix

  1. Attribute.sql_comment restores :{original_type}: when the attribute has one (falling back to :uuid:), so the copied column carries the same marker the parent was declared with.
  2. compile_foreign_key records each copied column's comment in the declaration's column_comments, so PostgreSQL emits COMMENT ON COLUMN for it. On MySQL column_comment_ddl returns None, so nothing changes there.
Lenguaje dominante
Python
Estrellas
197
Forks
99
Merge medio
1 d 11 h
PR fusionados (30 d)
10

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 datajoint/datajoint-python

Todos los issues de datajoint/datajoint-python

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.