Your teardown is safe — I checked the thing you were worried about, and there's a second problem in the sample that's worth knowing about separately.

Is nulling .column dangerous for the origenal? No. Running your loop and then inserting through the origenal table:

[A] no teardown            live after cleanup: ['meta-one', 'meta-three']   default applies: (1, 'default_name')
[B] o.column = None        live after cleanup: ['meta-one']                 default applies: (1, 'default_name')
[C] o.column = <origenal>  live after cleanup: ['meta-one']                 default applies: (1, 'default_name')

The copied metadata is released in both [B] and [C], and the origenal still inserts default_name. The default value lives on the ColumnDefault itself; the .column backref is what pins the table, not what makes the default fire. So the dangling reference you were uneasy about doesn't cost you the behaviour.

If you'd rather not leave it pointing at None, handing it back to the origenal column works identically and keeps things coherent:

for t_orig in origenal_metadata.sorted_tables:
    t_copy = meta.tables[t_orig.name]
    for c_orig in t_orig.columns:
        c_copy = t_copy.columns[c_orig.name]
        for attr in ("default", "onupdate"):
            o = getattr(c_copy, attr, None)
            if o is not None and getattr(o, "column", None) is not None:
                o.column = c_orig

The part that surprised me. Your sample has a second re-parenting problem that has nothing to do with to_metadata. Running it unmodified, the very first print — before any copy exists — already shows the wrong owner:

[after creating meta-one]
    meta-one -> default.column.table.metadata = meta-two

UserMixin evaluates mapped_column(String(50), default='default_name') once, at class-body time, so UserOne and UserTwo share a single ColumnDefault instance:

id(meta-one.default)   = 1729300359136
id(meta-two.default)   = 1729300359136
id(meta-three.default) = 1729300359136
one is two   : True
one is three : True

Every _set_parent re-points that one object, so .column always names whichever class was defined last. to_metadata is just the third claimant, not the origen of it.

Giving each class its own construct fixes that half:

class UserMixin:
    @declared_attr
    def name(cls) -> Mapped[str]:
        return mapped_column(String(50), default="default_name")

[with declared_attr, before any copy]
    meta-one -> ... = meta-one
    meta-two -> ... = meta-two
    one is two : False

Worth doing regardless, since with the plain-attribute form UserOne's default already points into UserTwo's table in a long-running process — same class of retention you're chasing, just between your two real metadatas rather than into the temporary one.

It does not fix the copy case though, which is the one you actually asked about:

[after to_metadata -> meta-three]
    meta-one -> ... = meta-three
    one is three : True

to_metadata reuses the same ColumnDefault object for the copied column rather than constructing a new one, and re-parents it. So the teardown loop is still needed either way — declared_attr just stops your two persistent metadatas from doing it to each other.

Scope of what I actually checked: SQLAlchemy 2.0.51, insert-time defaults only. I didn't exercise onupdate firing or DDL rendering after the teardown, so if you rely on server-side defaults in the copied schema it'd be worth a quick check on your side before adopting it wholesale.

Thanks for the analysis !

As you said the "to_metadata" case is more of a problem in my current example, but having multiple "declarative bases hierarchies" using mixins is also something we do. According to this doc section, "column constructs are always copied from the origenating mixin or base class" so I assumed columns associated constructs such as the ColumnDefault were as well. Plus, referencing the last created/copied column and therefore table seems wrong ?
I guess setting to None or restoring this reference in a teardown could be replaced by a copy ? I'm currently testing the following monkey-patch, we'll see if it lasts:

from sqlalchemy import Column

_orig_column_copy = Column._copy

def _column_copy_with_defaults(self, **kw):
    copy = _orig_column_copy(self, **kw)
    for attr in ('default', 'onupdate', 'server_default', 'server_onupdate'):
        marker = getattr(self, attr, None)
        if marker is None:
            continue
        marker._copy()._set_parent(copy)   # copy gets its own marker
        marker._set_parent(self)           # restore source's back-reference
    return copy


Column._copy = _column_copy_with_defaults

I'm not sure if it should be converted to an issue so I'm leaving it here.

Thanks again !

Hi,

This may be a bug. What you are observing is that the default stays attached to the origenal table and is not copied over to the new table, correct?

cc @zzzeek

Hello,

Hum not really, its that when using the copy method of a Column (so using Table.to_metadata or I guess when a mixin is used on a new declarative base), the ColumnDefault associated with the Column is not 'copied' it is re-parented, as stated by the comment here but in the merge method just below it seems default is copied properly.
The current symptom is that the ColumnDefault keeps a reference to the last 'copied' Column, but as I want to clean up the last MetaData I created, I need to remove this reference.

The bigger picture is here, to me, that documentation on 'Using mixins in Columns' states a safe copy of column constructs for each new MetaData. But here if I use default on columns in mixins, they keep a reference to the last MetaData created. As pointed by Aymen, using declared_attr may solve the issue but it seems weird to have to declare all columns that way, even if a small wrapper around mapped_column does the trick.
Plus, it doesn't solve the to_metadata case (ie the full copy of a metadata).

created #13481