Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#1,578 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@dimitri-yatsenko y travaille déjà.

Depuis le 9/10/2026.

  • #1579 par @dimitri-yatsenko — ouverte

Évaluation

Difficulté
3/5
Temps estimé
Une demi-journée
Accessibilité débutants
25/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
mysql, postgresql, python
Domaine
database

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.
Langage dominant
Python
Étoiles
197
Forks
99
Merge moyen
1 j 11 h
PR mergées (30 j)
10

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de datajoint/datajoint-python

Toutes les issues de datajoint/datajoint-python

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.