🐛 Declare __tablename__ on the metaclass (improve pyright compatibility)

[estarfoo]

Move __tablename__ from a @declared_attr method on SQLModel to a declaration on SQLModelMetaclass, with the default set in SQLModelMetaclass.__new__ before class creation (unless the user supplied one).

This resolves the type-level contradiction between the ClassVar[str | Callable] declaration and the @declared_attr descriptor, letting __tablename__ = "my_table" work without # type: ignore for pyright.

Caveat: dynamically computed names via @declared_attr.directive (per @YuriiMotov's review below) type-check in pyright basic mode. In standard/strict mode, one reportIncompatibleVariableOverride diagnostic remains.

Tests added for default name, explicit override, inheritance, non-table models, and the @declared_attr.directive form.

Fixes#98.

This is split out from #1820, dropping those changes which would be resolved by #1345 or #1806.

(Description edited following source branch update from 24d66f7 to 415c8fc.)

[YuriiMotov]

Spent a little time on reviewing this PR and haven't found any issues so far. All seems to work well.

Would be also good to fix the case with dynamically created table names as well:

from pydantic.alias_generators import to_snake
from sqlalchemy.orm import declared_attr
from sqlmodel import Field, SQLModel
class FirstWidget(SQLModel):
id: int | None = Field(default=None, primary_key=True)
name: str
@declared_attr.directive
@classmethod
def __tablename__(cls) -> str:
return to_snake(cls.__name__)
assert FirstWidget.__tablename__ == "first_widget"

Works well, but pyright argues:

[estarfoo]

@YuriiMotov, thank you very much for the review! Sorry for being slow to get back to this.

I agree that the dynamic table name is a valid use case and deserves support along with the static case. However:

• SQLAlchemy doesn't seem to export the type for @declared_attr.directive. To match it exactly, I'd have to import the private name, which I assume nobody would want:

fromsqlalchemy.orm.decl_apiimport_declared_directive# …__tablename__: ClassVar[str|Callable[..., str] |_declared_directive[str]]

• __tablename__ is Any in SQLAlchemy's DeclarativeBase anyway. I can do this:

__tablename__: ClassVar[Any]

But the second option loses typing for table names. Any preference, or do you maybe see another way?

[estarfoo]

@YuriiMotov, following up on dynamic table names: neither option from above turned out to be satisfying, so here's a rework shifting the __tablename__ declaration itself, not just its default value.

The current version would still produce a pyright message. I don't see a way around this at the moment, and I think it's an intrinsic limitation coming from SQLAlchemy. I'm open to suggestions on this, though!

[estarfoo]

Move __tablename__ from a @declared_attr method on SQLModel to a declaration on SQLModelMetaclass, with the default set in SQLModelMetaclass.__new__ before class creation (unless the user supplied one).

This resolves the type-level contradiction between the ClassVar[str | Callable] declaration and the @declared_attr descriptor, letting __tablename__ = "my_table" work without # type: ignore for pyright.

Caveat: dynamically computed names via @declared_attr.directive (per @YuriiMotov's review below) type-check in pyright basic mode. In standard/strict mode, one reportIncompatibleVariableOverride diagnostic remains.

Tests added for default name, explicit override, inheritance, non-table models, and the @declared_attr.directive form.

Fixes#98.

This is split out from #1820, dropping those changes which would be resolved by #1345 or #1806.

(Description edited following source branch update from 24d66f7 to 415c8fc.)

[YuriiMotov]

Spent a little time on reviewing this PR and haven't found any issues so far. All seems to work well.

Would be also good to fix the case with dynamically created table names as well:

from pydantic.alias_generators import to_snake
from sqlalchemy.orm import declared_attr
from sqlmodel import Field, SQLModel
class FirstWidget(SQLModel):
id: int | None = Field(default=None, primary_key=True)
name: str
@declared_attr.directive
@classmethod
def __tablename__(cls) -> str:
return to_snake(cls.__name__)
assert FirstWidget.__tablename__ == "first_widget"

Works well, but pyright argues:

[estarfoo]

@YuriiMotov, thank you very much for the review! Sorry for being slow to get back to this.

I agree that the dynamic table name is a valid use case and deserves support along with the static case. However:

• SQLAlchemy doesn't seem to export the type for @declared_attr.directive. To match it exactly, I'd have to import the private name, which I assume nobody would want:

fromsqlalchemy.orm.decl_apiimport_declared_directive# …__tablename__: ClassVar[str|Callable[..., str] |_declared_directive[str]]

• __tablename__ is Any in SQLAlchemy's DeclarativeBase anyway. I can do this:

__tablename__: ClassVar[Any]

But the second option loses typing for table names. Any preference, or do you maybe see another way?

[estarfoo]

@YuriiMotov, following up on dynamic table names: neither option from above turned out to be satisfying, so here's a rework shifting the __tablename__ declaration itself, not just its default value.

The current version would still produce a pyright message. I don't see a way around this at the moment, and I think it's an intrinsic limitation coming from SQLAlchemy. I'm open to suggestions on this, though!

[estarfoo]

Move __tablename__ from a @declared_attr method on SQLModel to a declaration on SQLModelMetaclass, with the default set in SQLModelMetaclass.__new__ before class creation (unless the user supplied one).

This resolves the type-level contradiction between the ClassVar[str | Callable] declaration and the @declared_attr descriptor, letting __tablename__ = "my_table" work without # type: ignore for pyright.

Caveat: dynamically computed names via @declared_attr.directive (per @YuriiMotov's review below) type-check in pyright basic mode. In standard/strict mode, one reportIncompatibleVariableOverride diagnostic remains.

Tests added for default name, explicit override, inheritance, non-table models, and the @declared_attr.directive form.

Fixes#98.

This is split out from #1820, dropping those changes which would be resolved by #1345 or #1806.

(Description edited following source branch update from 24d66f7 to 415c8fc.)

[YuriiMotov]

Spent a little time on reviewing this PR and haven't found any issues so far. All seems to work well.

Would be also good to fix the case with dynamically created table names as well:

from pydantic.alias_generators import to_snake
from sqlalchemy.orm import declared_attr
from sqlmodel import Field, SQLModel
class FirstWidget(SQLModel):
id: int | None = Field(default=None, primary_key=True)
name: str
@declared_attr.directive
@classmethod
def __tablename__(cls) -> str:
return to_snake(cls.__name__)
assert FirstWidget.__tablename__ == "first_widget"

Works well, but pyright argues:

[estarfoo]

@YuriiMotov, thank you very much for the review! Sorry for being slow to get back to this.

I agree that the dynamic table name is a valid use case and deserves support along with the static case. However:

• SQLAlchemy doesn't seem to export the type for @declared_attr.directive. To match it exactly, I'd have to import the private name, which I assume nobody would want:

fromsqlalchemy.orm.decl_apiimport_declared_directive# …__tablename__: ClassVar[str|Callable[..., str] |_declared_directive[str]]

• __tablename__ is Any in SQLAlchemy's DeclarativeBase anyway. I can do this:

__tablename__: ClassVar[Any]

But the second option loses typing for table names. Any preference, or do you maybe see another way?

[estarfoo]

@YuriiMotov, following up on dynamic table names: neither option from above turned out to be satisfying, so here's a rework shifting the __tablename__ declaration itself, not just its default value.

The current version would still produce a pyright message. I don't see a way around this at the moment, and I think it's an intrinsic limitation coming from SQLAlchemy. I'm open to suggestions on this, though!

[estarfoo]

Move __tablename__ from a @declared_attr method on SQLModel to a declaration on SQLModelMetaclass, with the default set in SQLModelMetaclass.__new__ before class creation (unless the user supplied one).

This resolves the type-level contradiction between the ClassVar[str | Callable] declaration and the @declared_attr descriptor, letting __tablename__ = "my_table" work without # type: ignore for pyright.

Caveat: dynamically computed names via @declared_attr.directive (per @YuriiMotov's review below) type-check in pyright basic mode. In standard/strict mode, one reportIncompatibleVariableOverride diagnostic remains.

Tests added for default name, explicit override, inheritance, non-table models, and the @declared_attr.directive form.

Fixes#98.

This is split out from #1820, dropping those changes which would be resolved by #1345 or #1806.

(Description edited following source branch update from 24d66f7 to 415c8fc.)

[YuriiMotov]

Spent a little time on reviewing this PR and haven't found any issues so far. All seems to work well.

Would be also good to fix the case with dynamically created table names as well:

from pydantic.alias_generators import to_snake
from sqlalchemy.orm import declared_attr
from sqlmodel import Field, SQLModel
class FirstWidget(SQLModel):
id: int | None = Field(default=None, primary_key=True)
name: str
@declared_attr.directive
@classmethod
def __tablename__(cls) -> str:
return to_snake(cls.__name__)
assert FirstWidget.__tablename__ == "first_widget"

Works well, but pyright argues:

[estarfoo]

@YuriiMotov, thank you very much for the review! Sorry for being slow to get back to this.

I agree that the dynamic table name is a valid use case and deserves support along with the static case. However:

• SQLAlchemy doesn't seem to export the type for @declared_attr.directive. To match it exactly, I'd have to import the private name, which I assume nobody would want:

fromsqlalchemy.orm.decl_apiimport_declared_directive# …__tablename__: ClassVar[str|Callable[..., str] |_declared_directive[str]]

• __tablename__ is Any in SQLAlchemy's DeclarativeBase anyway. I can do this:

__tablename__: ClassVar[Any]

But the second option loses typing for table names. Any preference, or do you maybe see another way?

[estarfoo]

@YuriiMotov, following up on dynamic table names: neither option from above turned out to be satisfying, so here's a rework shifting the __tablename__ declaration itself, not just its default value.

The current version would still produce a pyright message. I don't see a way around this at the moment, and I think it's an intrinsic limitation coming from SQLAlchemy. I'm open to suggestions on this, though!

[estarfoo]

Move __tablename__ from a @declared_attr method on SQLModel to a declaration on SQLModelMetaclass, with the default set in SQLModelMetaclass.__new__ before class creation (unless the user supplied one).

This resolves the type-level contradiction between the ClassVar[str | Callable] declaration and the @declared_attr descriptor, letting __tablename__ = "my_table" work without # type: ignore for pyright.

Caveat: dynamically computed names via @declared_attr.directive (per @YuriiMotov's review below) type-check in pyright basic mode. In standard/strict mode, one reportIncompatibleVariableOverride diagnostic remains.

Tests added for default name, explicit override, inheritance, non-table models, and the @declared_attr.directive form.

Fixes#98.

This is split out from #1820, dropping those changes which would be resolved by #1345 or #1806.

(Description edited following source branch update from 24d66f7 to 415c8fc.)

[YuriiMotov]

Spent a little time on reviewing this PR and haven't found any issues so far. All seems to work well.

Would be also good to fix the case with dynamically created table names as well:

from pydantic.alias_generators import to_snake
from sqlalchemy.orm import declared_attr
from sqlmodel import Field, SQLModel
class FirstWidget(SQLModel):
id: int | None = Field(default=None, primary_key=True)
name: str
@declared_attr.directive
@classmethod
def __tablename__(cls) -> str:
return to_snake(cls.__name__)
assert FirstWidget.__tablename__ == "first_widget"

Works well, but pyright argues:

[estarfoo]

@YuriiMotov, thank you very much for the review! Sorry for being slow to get back to this.

I agree that the dynamic table name is a valid use case and deserves support along with the static case. However:

• SQLAlchemy doesn't seem to export the type for @declared_attr.directive. To match it exactly, I'd have to import the private name, which I assume nobody would want:

fromsqlalchemy.orm.decl_apiimport_declared_directive# …__tablename__: ClassVar[str|Callable[..., str] |_declared_directive[str]]

• __tablename__ is Any in SQLAlchemy's DeclarativeBase anyway. I can do this:

__tablename__: ClassVar[Any]

But the second option loses typing for table names. Any preference, or do you maybe see another way?

[estarfoo]

@YuriiMotov, following up on dynamic table names: neither option from above turned out to be satisfying, so here's a rework shifting the __tablename__ declaration itself, not just its default value.

The current version would still produce a pyright message. I don't see a way around this at the moment, and I think it's an intrinsic limitation coming from SQLAlchemy. I'm open to suggestions on this, though!

[estarfoo]

Move __tablename__ from a @declared_attr method on SQLModel to a declaration on SQLModelMetaclass, with the default set in SQLModelMetaclass.__new__ before class creation (unless the user supplied one).

This resolves the type-level contradiction between the ClassVar[str | Callable] declaration and the @declared_attr descriptor, letting __tablename__ = "my_table" work without # type: ignore for pyright.

Caveat: dynamically computed names via @declared_attr.directive (per @YuriiMotov's review below) type-check in pyright basic mode. In standard/strict mode, one reportIncompatibleVariableOverride diagnostic remains.

Tests added for default name, explicit override, inheritance, non-table models, and the @declared_attr.directive form.

Fixes#98.

This is split out from #1820, dropping those changes which would be resolved by #1345 or #1806.

(Description edited following source branch update from 24d66f7 to 415c8fc.)

[YuriiMotov]

Spent a little time on reviewing this PR and haven't found any issues so far. All seems to work well.

Would be also good to fix the case with dynamically created table names as well:

from pydantic.alias_generators import to_snake
from sqlalchemy.orm import declared_attr
from sqlmodel import Field, SQLModel
class FirstWidget(SQLModel):
id: int | None = Field(default=None, primary_key=True)
name: str
@declared_attr.directive
@classmethod
def __tablename__(cls) -> str:
return to_snake(cls.__name__)
assert FirstWidget.__tablename__ == "first_widget"

Works well, but pyright argues:

[estarfoo]

@YuriiMotov, thank you very much for the review! Sorry for being slow to get back to this.

I agree that the dynamic table name is a valid use case and deserves support along with the static case. However:

• SQLAlchemy doesn't seem to export the type for @declared_attr.directive. To match it exactly, I'd have to import the private name, which I assume nobody would want:

fromsqlalchemy.orm.decl_apiimport_declared_directive# …__tablename__: ClassVar[str|Callable[..., str] |_declared_directive[str]]

• __tablename__ is Any in SQLAlchemy's DeclarativeBase anyway. I can do this:

__tablename__: ClassVar[Any]

But the second option loses typing for table names. Any preference, or do you maybe see another way?

[estarfoo]

@YuriiMotov, following up on dynamic table names: neither option from above turned out to be satisfying, so here's a rework shifting the __tablename__ declaration itself, not just its default value.

The current version would still produce a pyright message. I don't see a way around this at the moment, and I think it's an intrinsic limitation coming from SQLAlchemy. I'm open to suggestions on this, though!

[estarfoo]

Move __tablename__ from a @declared_attr method on SQLModel to a declaration on SQLModelMetaclass, with the default set in SQLModelMetaclass.__new__ before class creation (unless the user supplied one).

This resolves the type-level contradiction between the ClassVar[str | Callable] declaration and the @declared_attr descriptor, letting __tablename__ = "my_table" work without # type: ignore for pyright.

Caveat: dynamically computed names via @declared_attr.directive (per @YuriiMotov's review below) type-check in pyright basic mode. In standard/strict mode, one reportIncompatibleVariableOverride diagnostic remains.

Tests added for default name, explicit override, inheritance, non-table models, and the @declared_attr.directive form.

Fixes#98.

This is split out from #1820, dropping those changes which would be resolved by #1345 or #1806.

(Description edited following source branch update from 24d66f7 to 415c8fc.)

[YuriiMotov]

Spent a little time on reviewing this PR and haven't found any issues so far. All seems to work well.

Would be also good to fix the case with dynamically created table names as well:

from pydantic.alias_generators import to_snake
from sqlalchemy.orm import declared_attr
from sqlmodel import Field, SQLModel
class FirstWidget(SQLModel):
id: int | None = Field(default=None, primary_key=True)
name: str
@declared_attr.directive
@classmethod
def __tablename__(cls) -> str:
return to_snake(cls.__name__)
assert FirstWidget.__tablename__ == "first_widget"

Works well, but pyright argues:

[estarfoo]

@YuriiMotov, thank you very much for the review! Sorry for being slow to get back to this.

I agree that the dynamic table name is a valid use case and deserves support along with the static case. However:

• SQLAlchemy doesn't seem to export the type for @declared_attr.directive. To match it exactly, I'd have to import the private name, which I assume nobody would want:

fromsqlalchemy.orm.decl_apiimport_declared_directive# …__tablename__: ClassVar[str|Callable[..., str] |_declared_directive[str]]

• __tablename__ is Any in SQLAlchemy's DeclarativeBase anyway. I can do this:

__tablename__: ClassVar[Any]

But the second option loses typing for table names. Any preference, or do you maybe see another way?

[estarfoo]

@YuriiMotov, following up on dynamic table names: neither option from above turned out to be satisfying, so here's a rework shifting the __tablename__ declaration itself, not just its default value.

The current version would still produce a pyright message. I don't see a way around this at the moment, and I think it's an intrinsic limitation coming from SQLAlchemy. I'm open to suggestions on this, though!

[estarfoo]

Move __tablename__ from a @declared_attr method on SQLModel to a declaration on SQLModelMetaclass, with the default set in SQLModelMetaclass.__new__ before class creation (unless the user supplied one).

This resolves the type-level contradiction between the ClassVar[str | Callable] declaration and the @declared_attr descriptor, letting __tablename__ = "my_table" work without # type: ignore for pyright.

Caveat: dynamically computed names via @declared_attr.directive (per @YuriiMotov's review below) type-check in pyright basic mode. In standard/strict mode, one reportIncompatibleVariableOverride diagnostic remains.

Tests added for default name, explicit override, inheritance, non-table models, and the @declared_attr.directive form.

Fixes#98.

This is split out from #1820, dropping those changes which would be resolved by #1345 or #1806.

(Description edited following source branch update from 24d66f7 to 415c8fc.)

[YuriiMotov]

Spent a little time on reviewing this PR and haven't found any issues so far. All seems to work well.

Would be also good to fix the case with dynamically created table names as well:

from pydantic.alias_generators import to_snake
from sqlalchemy.orm import declared_attr
from sqlmodel import Field, SQLModel
class FirstWidget(SQLModel):
id: int | None = Field(default=None, primary_key=True)
name: str
@declared_attr.directive
@classmethod
def __tablename__(cls) -> str:
return to_snake(cls.__name__)
assert FirstWidget.__tablename__ == "first_widget"

Works well, but pyright argues:

[estarfoo]

@YuriiMotov, thank you very much for the review! Sorry for being slow to get back to this.

I agree that the dynamic table name is a valid use case and deserves support along with the static case. However:

• SQLAlchemy doesn't seem to export the type for @declared_attr.directive. To match it exactly, I'd have to import the private name, which I assume nobody would want:

fromsqlalchemy.orm.decl_apiimport_declared_directive# …__tablename__: ClassVar[str|Callable[..., str] |_declared_directive[str]]

• __tablename__ is Any in SQLAlchemy's DeclarativeBase anyway. I can do this:

__tablename__: ClassVar[Any]

But the second option loses typing for table names. Any preference, or do you maybe see another way?

[estarfoo]

@YuriiMotov, following up on dynamic table names: neither option from above turned out to be satisfying, so here's a rework shifting the __tablename__ declaration itself, not just its default value.

The current version would still produce a pyright message. I don't see a way around this at the moment, and I think it's an intrinsic limitation coming from SQLAlchemy. I'm open to suggestions on this, though!