On 4/5/15 12:32 AM, Russ wrote:
> I have some buried-in-the-codebase-since-0.7 upsert code that uses
> `merge`.  In order to avoid certain attributes from being used in the
> merge comparison, the attributes were deleted using delattr..
>
> The code looks something like this:
>
> db_obj = sess.query(obj_type).filter_by(**filters).one()
> pk = obj.__mapper__.primary_key[0].name
> setattr(obj, pk, getattr(db_obj, pk))  #convince merge they're comparable
> for attr in merge_ignores:
>     #See http://goo.gl/oBbpp for why we delete the attribute to avoid
> comparison
>     delattr(obj, attr)
> obj = sess.merge(obj)
>
> I've recently been trying 1.0.0b4, and now 1.0.0b5 and this code no
> longer works.
>
> Specifically, the code throws a KeyError on the delattr line. Here's
> the clipped traceback:
>
> File
> "/home/russ/code/bitbucket/sqlalchemy/lib/sqlalchemy/orm/attributes.py",
> line 227, in __delete__
>   self.impl.delete(instance_state(instance), instance_dict(instance))
> File
> "/home/russ/code/bitbucket/sqlalchemy/lib/sqlalchemy/orm/attributes.py",
> line 738, in delete
>   del dict_[self.key]
>
> KeyError: 'date_added_log'
>
> The attribute *definitely* exists at the time (albeit with a value of
> `None`, but it's there).  I doubt it matters, but obj is an instance
> of declarative_base'd class.  
>
> I see that __slots__ has been introduced to
> `ScalarObjectAttributeImpl`, which is where the is tanking.  __slots__
> seems like a likely candidate here, but I have to dig further.
>
> For now I've reverted back to 0.9.9 so the code works again.
>
> Is there some less sketchy way (that works in 1.0!) to force merge to
> not look at certain fields?
I absolutely need a succinct test case here.   __slots__ does not refer
to your object's state, only the state of internal structures with fixed
attributes.    Looking shortly it seems as simple as there's an
attribute you expected to be loaded that didn't actually load.    For
scalar attrs, only if perhaps the attr were marked as "deferred" might
it not be loaded in quite as many cases as it was in 0.9, as a deferred
attr won't load unless explicitly undeferred now.




>
> Russ
>
> -- 
> 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 http://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 http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.

Reply via email to