I'm happy for the change. Having getattr (and even hasattr!) change the state of the object was occasionally infuriating to debug, because my variable watches would trigger state changes, and cause data to be overwritten with NULLs.
I'll have to dig into my code a little deeper and figure out a workaround. Thanks! On Wed, Jan 6, 2016 at 1:50 PM, Mike Bayer <mike...@zzzcomputing.com> wrote: > > > On 01/06/2016 04:35 PM, Christopher Lee wrote: > > > > My code tests to see if an column on a model is loaded, in part because > > I merge partial models to perform a sparse update on the database. I do > > that by checking the __dict__ of the model, though sqlalchemy.inspect > > also works. > > > > Using SQLAlchemy 0.8.0: > > > > > > import sqlalchemy as sa > > import sqlalchemy.ext.declarative > > Base = sa.ext.declarative.declarative_base() > > > > class Foo(Base): > > __tablename__ = 'foos' > > x = sa.Column(sa.String(36), primary_key=True) > > > > foo = Foo() > > > > # Test unloaded attribute > >>>> 'x' in foo.__dict__ > > False > >>>> sa.inspect(foo).unloaded > > set(['x']) > > > > # Access attribute > >>>> foo.x > > > > # Test loaded attribute > >>>> 'x' in foo.__dict__ > > True > >>>> sa.inspect(foo).unloaded > > set([]) > > > > However, in sqlalchemy 1.0.10, that is no longer the case. The > > attribute is still marked as unloaded, and does not appear in the > > __dict__. Is that intentional, or is it a regression? > > that is intentional, details on this change are here: > > > http://docs.sqlalchemy.org/en/rel_1_0/changelog/migration_10.html#changes-to-attribute-events-and-other-operations-regarding-attributes-that-have-no-pre-existing-value > > the case directly below it illustrates why this consistency is important: > > > http://docs.sqlalchemy.org/en/rel_1_0/changelog/migration_10.html#priority-of-attribute-changes-on-relationship-bound-attributes-vs-fk-bound-may-appear-to-change > > If I were writing SQLAlchemy today, I'd probably have done away with > this behavior entirely and it would be emitting AttributeError just like > regular Python. > > > > Setting the > > attribute marks it as loaded, as expected. > I haven't narrowed down the > > issue to a specific version, because I wasn't sure if it is intentional. > > (i.e., maybe attributes are only marked as loaded if they are a > > relationship)? > > > > -- > > You received this message because you are subscribed to the Google > > Groups "sqlalchemy" group. > > To unsubscribe from this group and stop receiving emails from it, send > > an email to sqlalchemy+unsubscr...@googlegroups.com > > <mailto:sqlalchemy+unsubscr...@googlegroups.com>. > > To post to this group, send email to sqlalchemy@googlegroups.com > > <mailto:sqlalchemy@googlegroups.com>. > > Visit this group at https://groups.google.com/group/sqlalchemy. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sqlalchemy+unsubscr...@googlegroups.com. > To post to this group, send email to sqlalchemy@googlegroups.com. > Visit this group at https://groups.google.com/group/sqlalchemy. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
