Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#1,578 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@dimitri-yatsenko がすでに取り組んでいます。

2026年10月9日 から。

  • #1579 @dimitri-yatsenko による — オープン

評価

難易度
3/5
見積もり時間
半日
初心者へのやさしさ
25/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
停滞
技術スタック
mysql, postgresql, python
領域
database

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.
主要言語
Python
スター
197
フォーク
98
平均マージ
15時間 31分
マージ済み PR（30日）
9

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

datajoint/datajoint-python のほかの issue

datajoint/datajoint-python の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。