Ah, thanks very much, that's fixed it. I must have missed that in the docs
- I think this started out as a Python property and they later added the
hybrid decorator.
On Thursday, December 19, 2019 at 4:34:34 PM UTC-4, YKdvd wrote:
>
> We have a "Users" model with this, which was a hybrid
here's the migration note that includes this information:
https://docs.sqlalchemy.org/en/13/changelog/migration_12.html#hybrid-attributes-support-reuse-among-subclasses-redefinition-of-getter
On Thu, Dec 19, 2019, at 7:18 PM, Mike Bayer wrote:
> hiya -
>
> going to say right off this is the
hiya -
going to say right off this is the naming issue, there's an unfortunately
stalled PR to make sure the documentation emphasizes this at
https://github.com/sqlalchemy/sqlalchemy/pull/4970 . basically the same note as
you see in
We have a "Users" model with this, which was a hybrid property to wrap the
"email" column temporarily. The database column (MySQL 5.7) is "email",
but defined by ORM as "_email", with an "email" hybrid property to access
and set:
_email = Column(u'email', String(255))
...
@hybrid_property
On Thu, Dec 19, 2019, at 8:51 AM, Chris Wilson wrote:
> Dear Mike and SQLAlchemy users,
>
> I think I’ve discovered a confusing (and undocumented) limitation of the
> refresh_flush event. It’s called when non-PK columns are populated after an
> INSERT or UPDATE (e.g. from a server-side
Dear Mike and SQLAlchemy users,
I think I've discovered a confusing (and undocumented) limitation of the
refresh_flush event. It's called when non-PK columns are populated after an
INSERT or UPDATE (e.g. from a server-side default), but not for PK values.
The
