I think i didn't explain the error enough; just calling del user.name in the 
example below causes an exception (except when i already accessed (say print 
user.name) the attribute, which seemed odd to me). This is independent of 
whether the attr becomes None. 

Otherwise it isn't a real problem in my code, just something i ran into while 
cleaning up some internal api, as you say i can easily work around it.

Cheers, Lars



====================================
Lars van Gemerden
[email protected]
+31 6 26 88 55 39
====================================

On 13 jul. 2013, at 01:52, Michael Bayer <[email protected]> wrote:

> There's all kinds of things that __delete__ should possibly do, most likely 
> just do what you expect, i.e. set the value to NULL, but this would be 
> changing its behavior in a very backwards-incompatible way; such a change 
> could only be considered for 0.9.    
> 
> Whats not clear is how exactly an entire application was built around 0.7, 
> relying on "del" in some way such that this can no longer be changed, and 
> suddenly it's an issue?  doesn't make sense, I don't see why you can't just 
> get replace those "del" statements on your end.  It's not supported, and if 
> it were, it would not be in 0.7 or 0.8.
> 
> 
> 
> On Jul 12, 2013, at 6:11 PM, Lars van Gemerden <[email protected]> wrote:
> 
>> After thinking on it some more, should InstrumentedAttribute.__delete__ even 
>> exist then, or maybe raise a NotImplementedError?
>> 
>> CL
>> 
>> ====================================
>> Lars van Gemerden
>> [email protected]
>> +31 6 26 88 55 39
>> ====================================
>> 
>> On 12 jul. 2013, at 18:28, Michael Bayer <[email protected]> wrote:
>> 
>>> We've never supported "del obj.attrname" as a means of setting an attribute 
>>> to None (which translates to NULL in SQL).   Setting the value to None 
>>> explicitly is preferred.
>>> 
>>> On Jul 12, 2013, at 12:16 PM, lars van gemerden <[email protected]> 
>>> wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> I had an arror in my code and i think i have reconstructed it as follows:
>>>> 
>>>> -----------------------------------------------------------------------------------------------
>>>> 
>>>>         from sqlalchemy import Column, Integer, String
>>>>         from sqlalchemy import create_engine
>>>>         from sqlalchemy.orm import sessionmaker
>>>>         from sqlalchemy.ext.declarative import declarative_base
>>>> 
>>>>         Base = declarative_base()        
>>>>         engine = create_engine('sqlite:///:memory:', echo=True)
>>>>         Session = sessionmaker(bind=engine)
>>>>         
>>>>         class User(Base):
>>>>             __tablename__ = 'users'
>>>>             id = Column(Integer, primary_key=True)
>>>>             name = Column(String)
>>>>             
>>>>         Base.metadata.create_all(engine) 
>>>>             
>>>>         session = Session()
>>>>         user = User(name = 'bob')
>>>>         session.add(user)
>>>>         session.commit()
>>>>         #user.name
>>>>         del user.name #error in sqlalchemy file attributes.py line 529
>>>>         #user.name
>>>>         session.commit()
>>>>         assert user.name == None #error: user.name is still 'bob'
>>>> 
>>>> ------------------------------------------------------------------------------------------------------------
>>>> 
>>>> These two errors do not occur if i access the attributes before the delete 
>>>> or the commit (i.e. uncomment the #user.name lines).
>>>> 
>>>> I am using version 7.5; are these errors solved by the latest version?
>>>> 
>>>>  I would like to avoid upgrading at this point, but if i could be 
>>>> reasonably sure that upgrading solves the problem, then no problem ..
>>>> 
>>>> Cheers, Lars
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> 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 [email protected].
>>>> To post to this group, send email to [email protected].
>>>> Visit this group at http://groups.google.com/group/sqlalchemy.
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>> 
>>> 
>>> -- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "sqlalchemy" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/sqlalchemy/TRUmFTaDCF8/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> [email protected].
>>> To post to this group, send email to [email protected].
>>> Visit this group at http://groups.google.com/group/sqlalchemy.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>> 
>> 
>> -- 
>> 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 [email protected].
>> To post to this group, send email to [email protected].
>> Visit this group at http://groups.google.com/group/sqlalchemy.
>> For more options, visit https://groups.google.com/groups/opt_out.
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "sqlalchemy" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/sqlalchemy/TRUmFTaDCF8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/sqlalchemy.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to