Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#1,578 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@dimitri-yatsenko ci sta già lavorando.

Dal 9/10/2026.

  • #1579 di @dimitri-yatsenko — aperta

Valutazione

Difficoltà
3/5
Tempo stimato
Mezza giornata
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
mysql, postgresql, python
Ambito
database

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
Python
Stelle
197
Fork
99
Merge medio
1g 11h
PR unite (30g)
10

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di datajoint/datajoint-python

Tutte le issue di datajoint/datajoint-python

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.