Strange classes inside autogenerated migration file

[waldner]

After running piccolo migrations new --auto myapp, inspecting the generated python file I see these classes after the imports and before the ID etc metadata:

...
from piccolo.columns.indexes import IndexMethod
from piccolo.table import Table
import decimal

class Parts(Table, tablename="parts", schema=None):
    id = Serial(
        null=False,
        primary_key=True,
        unique=False,
        index=False,
        index_method=IndexMethod.btree,
        choices=None,
        db_column_name=None,
        secret=False,
    )
    id = Serial(
        null=False,
        primary_key=True,
        unique=False,
        index=False,
        index_method=IndexMethod.btree,
        choices=None,
        db_column_name=None,
        secret=False,
    )


class Pieces(Table, tablename="pieces", schema=None):
    id = Serial(
        null=False,
        primary_key=True,
        unique=False,
        index=False,
        index_method=IndexMethod.btree,
        choices=None,
        db_column_name=None,
        secret=False,
    )
    id = Serial(
        null=False,
        primary_key=True,
        unique=False,
        index=False,
        index_method=IndexMethod.btree,
        choices=None,
        db_column_name=None,
        secret=False,
    )


ID = "2025-05-14T21:48:44:914229"
VERSION = "1.26.0"
DESCRIPTION = ""

async def forwards():
...

Is this normal? What's the purpose, and why does id appear twice in each class?
There are more tables defined in myapp/tables.py, but only the two above have those autogenerated artifacts in the migration file.

[dantownsend]

Hmm, interesting - I'm not sure why there are two id columns defined.

The reason these tables get generated is for foreign keys. So something like this (the references value):

from piccolo.apps.migrations.auto import MigrationManager
from piccolo.columns import ForeignKey
from piccolo.columns.base import OnDelete
from piccolo.columns.base import OnUpdate
from piccolo.table import Table


class TaskCategory(Table, tablename="task_category"):
    pass


ID = "2025-05-10T11:26:44:292246"
VERSION = "X.X.X"


async def forwards():
    manager = MigrationManager(migration_id=ID, app_name="home")

    manager.add_column(
        table_class_name="Task",
        tablename="task",
        column_name="category",
        column_class_name="ForeignKey",
        column_class_name=ForeignKey,
        params={
            "references": TaskCategory,
            "on_delete": OnDelete.cascade,
            "on_update": OnUpdate.cascade,
            "default": None,
            "null": True,
            "primary": False,
            "key": False,
            "unique": False,
            "index": False,
        },
    )

    return manager

Is there anything in your schema which you think might be causing it?

[waldner]

Well, couldn't you just import the relevant classes from tables.py instead of autogenerating those incomplete classes?

Here is the definition for the two above tables (from tables.py):

class Pieces(Table, tablename="pieces"):

    id = Serial(primary_key=True, null=False)
    type = Text(null=False, required=True)
    description = Text(null=False, required=True)
    start_date = Date(null=False, required=True)
    timezone = Text(null=False, required=True)
    internal_id = Text(null=False, required=True)


class Parts(Table, tablename="parts"):

    id = Serial(primary_key=True, null=False)
    piece_id = ForeignKey(references=Pieces, target_column='id', null=True, required=True)
    description = Text(null=False, required=True)
    start_date = Date(null=False, required=True)
    internal_id = Text(null=False, required=True)

The null=True for the foreign key column is to work around the issue discussed here #1176

EDIT: ok, there's another table that has a foreign key into Parts so that might explain why it appears in the migration file. Still, the id shouldn't be duplicated imho.

[dantownsend]

Well, couldn't you just import the relevant classes from tables.py instead of autogenerating those incomplete classes?

The migration files are as self contained as possible, just in case tables are deleted in the future - the imports would then break.

Here is the definition for the two above tables (from tables.py):

Thanks - I was able to replicate the double id column. It seems like it's because of target_column='id'.

I need to change it, so it checks if the target column is already on the table, and if so don't add it.

piccolo/piccolo/apps/migrations/auto/serialisation.py

Lines 360 to 391 in bf4e64c

	#######################################################################
	# When creating a ForeignKey, the user can specify a column other than
	# the primary key to reference.
	serialised_target_columns: t.Set[SerialisedColumnInstance] = set()
	for fk_column in self.table_type._meta._foreign_key_references:
	target_column = fk_column._foreign_key_meta.target_column
	if target_column is None:
	# Just references the primary key
	continue
	elif type(target_column) is str:
	column = self.table_type._meta.get_column_by_name(
	target_column
	)
	elif isinstance(target_column, Column):
	column = self.table_type._meta.get_column_by_name(
	target_column._meta.name
	)
	else:
	raise ValueError("Unrecognised `target_column` value.")
	serialised_target_columns.add(
	SerialisedColumnInstance(
	column,
	serialised_params=serialise_params(
	params=column._meta.params
	),
	)
	)
	#######################################################################

[waldner]

Thanks! Waiting for the fix then.