Re: [sqlalchemy] Re: deferred column_properties should probably not be expired unless they were already loaded

Thanks very much! On Wed, May 10, 2017 at 2:24 PM, mike bayer wrote: > this is all patched in 1.2, your original test works too. > > The fix here is a little too intricate for 1.1 right now as this is a very > long-standing bug(goes back to 0.7 at least and

Re: [sqlalchemy] Re: deferred column_properties should probably not be expired unless they were already loaded

this is all patched in 1.2, your original test works too. The fix here is a little too intricate for 1.1 right now as this is a very long-standing bug (goes back to 0.7 at least and probably further) and 1.1 is getting near maintenance mode. On 05/10/2017 01:48 PM, mike bayer wrote:

Re: [sqlalchemy] Re: deferred column_properties should probably not be expired unless they were already loaded

On 05/10/2017 02:00 PM, Kent Bower wrote: If never present in __dict__, why does it need to be marked as expired after an insert or update? If not in __dict__ and referenced, isn't won't it load as whether or not it is marked as expired? if: 1. an attribute is a normal column-oriented

Re: [sqlalchemy] Re: deferred column_properties should probably not be expired unless they were already loaded

If never present in __dict__, why does it need to be marked as expired after an insert or update? If not in __dict__ and referenced, isn't won't it load as whether or not it is marked as expired? On Wed, May 10, 2017 at 1:48 PM, mike bayer wrote: > nevermind, the

Re: [sqlalchemy] Re: deferred column_properties should probably not be expired unless they were already loaded

nevermind, the issue is at https://bitbucket.org/zzzeek/sqlalchemy/issues/3984/deferred-column_property-gets-set-to the fix is not as obvious as that, that particular check is assuming a column_property() where its value was never present in __dict__ in the first place, so it needs to be

Re: [sqlalchemy] Re: deferred column_properties should probably not be expired unless they were already loaded

The regular columns seem to expire and reload properly without issue. (Is that what you're asking?) You want me to submit a PR changing: if p.expire_on_flush or p.key *not *in state.dict to if p.expire_on_flush *and *p.key in state.dict ? (If so, which branch?) On Wednesday, May 10,

Re: [sqlalchemy] Re: deferred column_properties should probably not be expired unless they were already loaded

The regular columns seem to expire and reload properly without issue. (Is that what you're asking?) You want me to submit a PR changing: if p.expire_on_flush or p.key *not *in state.dict to if p.expire_on_flush *and *p.key in state.dict ? On Wed, May 10, 2017 at 12:55 PM, mike bayer

Re: [sqlalchemy] Re: deferred column_properties should probably not be expired unless they were already loaded

so you can confirm this is only for custom SQL + column_property(), not a regular column right? definitely a bug for 1.2 if you can post it up On 05/10/2017 12:37 PM, Kent wrote: I'm thinking that should be *"if p.expire_on_flush and p.key in state.dict"* On Wednesday, May 10, 2017 at

[sqlalchemy] Re: deferred column_properties should probably not be expired unless they were already loaded

I'm thinking that should be *"if p.expire_on_flush and p.key in state.dict"* On Wednesday, May 10, 2017 at 11:35:30 AM UTC-4, Kent wrote: > > deferred column_properties may be less-efficient subquery selects (and > thus marked deferred). When a flush occurs that updates an object, any >

[sqlalchemy] Re: deferred column_properties should probably not be expired unless they were already loaded

Another question surrounding this: in persistence.py: def _finalize_insert_update_commands(...) if mapper._readonly_props: readonly = state.unmodified_intersection( [p.key for p in mapper._readonly_props if p.expire_on_flush or