Re: [sqlalchemy] Bug with bidirectional association proxy many-to-many relationships reintroduced?

2016-08-24 Thread Mike Bayer



On 08/24/2016 03:09 PM, Gordan Todorovac wrote:

Mike,



python -i ~/python/sq3.py

from sqlalchemy import create_engine
from sqlalchemy.orm import Session
e = create_engine("sqlite:///:memory:")
Base.metadata.drop_all(e)
Base.metadata.create_all(e)
session=Session(e)
rory=User("rory")
session.add(rory)
chicken=Keyword("chicken")
session.add(chicken)
rory.keywords.append(chicken)
rory.keywords

[Keyword('chicken')]

chicken.users

[<__main__.User object at 0x7f82dff87390>]



Here, nothing is flushed yet.  UserKeyword is a pending object and has 
not been inserted.




rory.keywords.remove(chicken)


Here, you've removed from User.user_keywords, marked the UserKeyword as 
deleted, and since it was never inserted, it's bumped out of the 
session.



rory.keywords

[]


rory.user_keywords is empty.


chicken.users

[None]


chicken.user_keywords still has the UserKeyword object stuck in it, the 
UserKeyword has no User attached to it, so the user name is None. 
There is no relationship between UserKeyword.keyword and 
UserKeyword.user, so you'd need to wait for the session to be expired 
and have this totally unrelated relationship load again, or perhaps use 
attribute events of your own to synchronize these ahead of re-loading.





session.flush()

/hostname/multiacl2/lib/python2.7/site-packages/sqlalchemy/orm/unitofwork.py:235:
SAWarning: Object of type  not in session, add operation
along 'Keyword.user_keywords' will not proceed


this warning is because this is an odd situation where you've added a 
UserKeyword as pending, never flushed it, and have now removed it from 
the session, but it's still sitting inside of a collection.




chicken.user_keywords

[<__main__.UserKeyword object at 0x7f82dfa6ded0>]


expected, same reasons above


chicken.user_keywords[0].user
chicken.user_keywords[0].keyword

Keyword('chicken')


expected, same reason above.

type "session.commit()".  Now everything is what you'd expect.

This is also explained in my answer at 
http://stackoverflow.com/a/14471166/34549.


The bug explained in that answer is that prior to 0.8, the UserKeyword 
object in question *would still be in the Session*, and since it's 
"user" is None, you get a NULL error - the original poster reported: 
"Causes an integrity error as SA tries to set one of the foreign key 
columns to null.".  That's the part that was fixed.










So it definitely seems that the association object is
half-disassociated. I have this currently worked around by setting a
validator on UserKeyword.user that removes self from
UserKeyword.keyword.user_keywords if self.user is None, but I am not
confident in this workaround.



On Wednesday, August 24, 2016 at 1:57:58 PM UTC-4, Mike Bayer wrote:



The issue mentioned in 2655 is a major behavior of the ORM, in that an
object is considered orphan if any of its relationships are non-present
in all cases, including pending and persistent, rather than if all of
them are un-present. This is not at all subtle and is covered in a
wide range of test cases.   The test case attached to the bug continues
to pass, as does the demonstration attached in the migration notes:

http://docs.sqlalchemy.org/en/latest/changelog/migration_08.html#the-consideration-of-a-pending-object-as-an-orphan-has-been-made-more-aggressive

.



>
>
> Is anyone aware whether this bug was reintroduced on purpose (i.e.
> figured out the rationale for the original behavior) or by accident?

reintroduction of a bug here would need to be demonstrated.

--
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.


Re: [sqlalchemy] begin_nested 2 Table

2016-08-24 Thread lone ois
OK, you code is right.

i am fool.
my project table has own data conn class
subtable and maintable get different  session.
so is my bug.

Thank You.

-- 
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.


Re: [sqlalchemy] Bug with bidirectional association proxy many-to-many relationships reintroduced?

2016-08-24 Thread Gordan Todorovac
Mike,

Thanks for the response! Here is the demonstration, please let me know if 
there is something obvious that I am missing:

> cat ~/python/sq3.py
from sqlalchemy import Column, Integer, String, ForeignKey
from sqlalchemy.orm import relationship, backref

from sqlalchemy.ext.associationproxy import association_proxy
from sqlalchemy.ext.declarative import declarative_base

Base = declarative_base()

class User(Base):
__tablename__ = 'user'
id = Column(Integer, primary_key=True)
name = Column(String(64))

# association proxy of "user_keywords" collection
# to "keyword" attribute
keywords = association_proxy('user_keywords', 'keyword')

def __init__(self, name):
self.name = name

class UserKeyword(Base):
__tablename__ = 'user_keyword'
user_id = Column(Integer, ForeignKey('user.id'), primary_key=True)
keyword_id = Column(Integer, ForeignKey('keyword.id'), primary_key=True)
special_key = Column(String(50))

# bidirectional attribute/collection of "user"/"user_keywords"
user = relationship(User,
backref=backref("user_keywords",
cascade="all, delete-orphan")
)

keyword = relationship("Keyword",
backref=backref("user_keywords", cascade="all, 
delete-orphan"))

def __init__(self, keyword=None, user=None, special_key=None):
self.user = user
self.keyword = keyword
self.special_key = special_key

class Keyword(Base):
__tablename__ = 'keyword'
id = Column(Integer, primary_key=True)
keyword = Column('keyword', String(64))

users = association_proxy('user_keywords', 'user')

def __init__(self, keyword):
self.keyword = keyword

def __repr__(self):
return 'Keyword(%s)' % repr(self.keyword)

> python -i ~/python/sq3.py
>>> from sqlalchemy import create_engine
>>> from sqlalchemy.orm import Session
>>> e = create_engine("sqlite:///:memory:")
>>> Base.metadata.drop_all(e)
>>> Base.metadata.create_all(e)
>>> session=Session(e)
>>> rory=User("rory")
>>> session.add(rory)
>>> chicken=Keyword("chicken")
>>> session.add(chicken)
>>> rory.keywords.append(chicken)
>>> rory.keywords
[Keyword('chicken')]
>>> chicken.users
[<__main__.User object at 0x7f82dff87390>]
>>> rory.keywords.remove(chicken)
>>> rory.keywords
[]
>>> chicken.users
[None]
>>> session.flush()
/hostname/multiacl2/lib/python2.7/site-packages/sqlalchemy/orm/unitofwork.py:235:
 
SAWarning: Object of type  not in session, add operation along 
'Keyword.user_keywords' will not proceed
  (orm_util.state_class_str(state), operation, prop))
>>> chicken.user_keywords
[<__main__.UserKeyword object at 0x7f82dfa6ded0>]
>>> chicken.user_keywords[0].user
>>> chicken.user_keywords[0].keyword
Keyword('chicken')
>>>

So it definitely seems that the association object is half-disassociated. I 
have this currently worked around by setting a validator on 
UserKeyword.user that removes self from UserKeyword.keyword.user_keywords 
if self.user is None, but I am not confident in this workaround.



On Wednesday, August 24, 2016 at 1:57:58 PM UTC-4, Mike Bayer wrote:
>
>
>
> The issue mentioned in 2655 is a major behavior of the ORM, in that an 
> object is considered orphan if any of its relationships are non-present 
> in all cases, including pending and persistent, rather than if all of 
> them are un-present. This is not at all subtle and is covered in a 
> wide range of test cases.   The test case attached to the bug continues 
> to pass, as does the demonstration attached in the migration notes: 
>
> http://docs.sqlalchemy.org/en/latest/changelog/migration_08.html#the-consideration-of-a-pending-object-as-an-orphan-has-been-made-more-aggressive.
>  
>
>  
>
> > 
> > 
> > Is anyone aware whether this bug was reintroduced on purpose (i.e. 
> > figured out the rationale for the original behavior) or by accident? 
>
> reintroduction of a bug here would need to be demonstrated. 
>

-- 
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.


Re: [sqlalchemy] begin_nested 2 Table

2016-08-24 Thread Mike Bayer



On 08/24/2016 02:26 PM, lone ois wrote:

M2 = SubTable()

_conn.begin_nested()

M1.mainkey - "1"


MainTable has no attribute "mainkey" and I think this means to be an = sign.



M2.number = '1'
M2.name = '1'

_conn.add(M2)

_conn.commit()
except:
_conn.rollback()
else:
_conn.commit()


(psycopg2.IntegrityError) insert or update on table "SubTable" violates
foreign key constraint "SubTable_MainTable_fkey"
DETAIL: Key (mainkey)=(1) is not present in table "MainTable".


can't reproduce.  Test case attached, output:

2016-08-24 15:02:44,942 INFO sqlalchemy.engine.base.Engine BEGIN (implicit)
2016-08-24 15:02:44,943 INFO sqlalchemy.engine.base.Engine SAVEPOINT 
sa_savepoint_1

2016-08-24 15:02:44,943 INFO sqlalchemy.engine.base.Engine {}
2016-08-24 15:02:44,945 INFO sqlalchemy.engine.base.Engine INSERT INTO 
"MainTable" (number, name) VALUES (%(number)s, %(name)s) RETURNING 
"MainTable".id
2016-08-24 15:02:44,945 INFO sqlalchemy.engine.base.Engine {'name': 
'1', 'number': '1'}
2016-08-24 15:02:44,946 INFO sqlalchemy.engine.base.Engine RELEASE 
SAVEPOINT sa_savepoint_1

2016-08-24 15:02:44,946 INFO sqlalchemy.engine.base.Engine {}
2016-08-24 15:02:44,948 INFO sqlalchemy.engine.base.Engine SAVEPOINT 
sa_savepoint_2

2016-08-24 15:02:44,948 INFO sqlalchemy.engine.base.Engine {}
2016-08-24 15:02:44,949 INFO sqlalchemy.engine.base.Engine INSERT INTO 
"SubTable" (mainkey, number, name) VALUES (%(mainkey)s, %(number)s, 
%(name)s) RETURNING "SubTable".id
2016-08-24 15:02:44,950 INFO sqlalchemy.engine.base.Engine {'mainkey': 
None, 'number': '1', 'name': '1'}
2016-08-24 15:02:44,951 INFO sqlalchemy.engine.base.Engine RELEASE 
SAVEPOINT sa_savepoint_2

2016-08-24 15:02:44,951 INFO sqlalchemy.engine.base.Engine {}
2016-08-24 15:02:44,951 INFO sqlalchemy.engine.base.Engine COMMIT







the SA echo add(M2) before has BEGIN (implicit) again, and insert data
and rollback savepoint
-
how can save SubTable?
the example is short,
my project subtable has more table data modify.
so SAVEPOINT is must.
but i can't serach any fix
is add(M2) before again BEGIN (implicit) bug ?


I'd need to see a test case that illustrates the actual problem.






--
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.
from sqlalchemy import *
from sqlalchemy.orm import *
from sqlalchemy.ext.declarative import declarative_base

Base = declarative_base()

class MainTable(Base):
__tablename__ = 'MainTable'

id = Column(BIGINT, primary_key = True, autoincrement = True, unique = True)
number = Column(Text, unique=True, nullable=False)
name = Column(Text, unique=True, nullable = False)



class SubTable(Base):
__tablename__ = 'SubTable'

id = Column(BIGINT, primary_key = True, autoincrement = True, unique = True)
mainkey = Column(ForeignKey(MainTable.number))
number = Column(Text, unique = True, nullable = False)
name = Column(Text, unique = True, nullable = False)

e = create_engine("postgresql://scott:tiger@localhost/test", echo=True)
Base.metadata.drop_all(e)
Base.metadata.create_all(e)

_conn = Session(e)

try:
   M1=MainTable()

   _conn.begin_nested()

   M1.number = '1'
   M1.name = '1'
   _conn.add(M1)

   _conn.commit()



   M2 = SubTable()

   _conn.begin_nested()

   M1.mainkey = "1"
   M2.number = '1'
   M2.name = '1'

   _conn.add(M2)

   _conn.commit()
except:
   _conn.rollback()
   raise
else:
   _conn.commit()

[sqlalchemy] begin_nested 2 Table

2016-08-24 Thread lone ois


Hello ALL:
i has 2 table.

_Table_Metadata = declarative_base(cls = DictableModel)

class MainTable(_Table_Metadata):
__tablename__ = 'MainTable'

id = Column(BIGINT, primary_key = True, autoincrement = True, unique = True)
number = Column(Text, unique=True, nullable=False) 
name = Column(Text, unique=True, nullable = False)



class SubTable(_Table_Metadata):
__tablename__ = 'SubTable'

id = Column(BIGINT, primary_key = True, autoincrement = True, unique = True)
mainkey = Column(ForeignKey(MainTable.number))
number = Column(Text, unique = True, nullable = False)
name = Column(Text, unique = True, nullable = False)
-
try:
   _conn.execute('SAVEPOINT AAA;')
   _conn.execute("INSERT INTO MainTable(number, name) VALUES( '1', '1' 
);")
   _conn.execute('RELEASE SAVEPOINT AAA;')
   
   _conn.execute('SAVEPOINT AAA;')
   _conn.execute("INSERT INTO SubTable(mainkey, number, name) VALUES('1', 
'1', '1');")
   _conn.execute('RELEASE SAVEPOINT AAA;')
except:
   _conn.execute( 'ROLLBACK' )
else:
   _conn.execute("COMMIT")

is OK, 2 Table has record
-

try:
   M1=MainTable()
  
   _conn.begin_nested()
   
   M1.number = '1'
   M1.name = '1'
   _conn.add(M1)
   
   _conn.commit()

   
   
   M2 = SubTable()

   _conn.begin_nested()
   
   M1.mainkey - "1"  
   M2.number = '1'
   M2.name = '1'
   
   _conn.add(M2)  
   
   _conn.commit()
except:
   _conn.rollback()
else: 
   _conn.commit()

 
 (psycopg2.IntegrityError) insert or update on table "SubTable" violates 
foreign key constraint "SubTable_MainTable_fkey"
 DETAIL:  Key (mainkey)=(1) is not present in table "MainTable".
 
 
 the SA echo add(M2) before has BEGIN (implicit) again, and insert data and 
rollback savepoint 
-
how can save SubTable? 
the example is short,
my project subtable has more table data modify.
so SAVEPOINT is must.
but i can't serach any fix
is add(M2) before again BEGIN (implicit) bug ? 


-- 
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.


Re: [sqlalchemy] Bug with bidirectional association proxy many-to-many relationships reintroduced?

2016-08-24 Thread Mike Bayer



On 08/24/2016 08:59 AM, Gordan Todorovac wrote:

Hi, all -

I am experiencing the issue described here

http://stackoverflow.com/questions/14470688/sqlalchemy-bidirectional-relationship-association-proxy

and reported as fixed here

https://bitbucket.org/zzzeek/sqlalchemy/issues/2655


in the latest release version of SQLAlchemy (1.0.14). Summary: removing
a child object from the proxied (on parent) many-to-many relationship
using an association object does not remove the association object or
the reference to it from the child.


The issue mentioned in 2655 is a major behavior of the ORM, in that an 
object is considered orphan if any of its relationships are non-present 
in all cases, including pending and persistent, rather than if all of 
them are un-present. This is not at all subtle and is covered in a 
wide range of test cases.   The test case attached to the bug continues 
to pass, as does the demonstration attached in the migration notes: 
http://docs.sqlalchemy.org/en/latest/changelog/migration_08.html#the-consideration-of-a-pending-object-as-an-orphan-has-been-made-more-aggressive.






Is anyone aware whether this bug was reintroduced on purpose (i.e.
figured out the rationale for the original behavior) or by accident?


reintroduction of a bug here would need to be demonstrated.





Many thanks,


Gordan


--
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.


[sqlalchemy] Bug with bidirectional association proxy many-to-many relationships reintroduced?

2016-08-24 Thread Gordan Todorovac
Hi, all -

I am experiencing the issue described here

http://stackoverflow.com/questions/14470688/sqlalchemy-bidirectional-relationship-association-proxy

and reported as fixed here

https://bitbucket.org/zzzeek/sqlalchemy/issues/2655


in the latest release version of SQLAlchemy (1.0.14). Summary: removing a 
child object from the proxied (on parent) many-to-many relationship using 
an association object does not remove the association object or the 
reference to it from the child.


Is anyone aware whether this bug was reintroduced on purpose (i.e. figured 
out the rationale for the original behavior) or by accident?


Many thanks,


Gordan

-- 
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.


Re: [sqlalchemy] Re: Abusing a string column as list of foreign keys (own relationship class, based on DependencyProcessor?)

2016-08-24 Thread Mike Bayer



On 08/24/2016 04:39 AM, Torsten Landschoff wrote:

Hi all,

On Wednesday, August 24, 2016 at 3:17:55 AM UTC+2, Torsten Landschoff wrote:

I am currently pulling my hair out because I have a solution that I
think should work on the database side (albeit I don't like it), but
I can't figure out how to do this with sqlalchemy.
My current goal is to manage (long-lived) locks on copy-on-write
hierarchical data that is stored in Oracle RDBMS.


I case somebody was pondering about this, I think by sleeping over it
and discussing it with a colleague I found a more "normal" solution.
So don't spend too much time on this :-)


if you've already solved the problem I'd rather not get into it :)





Greetings, Torsten


--
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.


[sqlalchemy] Re: Abusing a string column as list of foreign keys (own relationship class, based on DependencyProcessor?)

2016-08-24 Thread Torsten Landschoff
Hi all,

On Wednesday, August 24, 2016 at 3:17:55 AM UTC+2, Torsten Landschoff wrote:
>
> I am currently pulling my hair out because I have a solution that I think 
> should work on the database side (albeit I don't like it), but I can't 
> figure out how to do this with sqlalchemy.
> My current goal is to manage (long-lived) locks on copy-on-write 
> hierarchical data that is stored in Oracle RDBMS.
>
>
I case somebody was pondering about this, I think by sleeping over it and 
discussing it with a colleague I found a more "normal" solution.
So don't spend too much time on this :-)

Greetings, Torsten
 

-- 
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.


[sqlalchemy] Re: Having SA generate constructor when using autoload.

2016-08-24 Thread Piotr Dobrogost
> On Monday, August 22, 2016 at 11:12:11 AM UTC+2, Piotr Dobrogost wrote:
>
> (...)
> Is there a way to hold off this check until after I map this class like 
this
>
> my_table = sa.Table("my_table", meta.metadata, autoload=True, 
autoload_with=engine)
> orm.mapper(MyClass, my_table)
>
> ?

It appears that what I really wanted is a way to use declarative base with 
autoload=True.
I found "SQLAlchemy declarative syntax with autoload (reflection) in 
Pylons" (http://stackoverflow.com/q/4526498/95735) which should solve my 
problem.

-- 
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.


Re: [sqlalchemy] hybrid_property vs. hybrid_method, other than the latter can take arguments?

2016-08-24 Thread Simon King
On Wed, Aug 24, 2016 at 2:55 AM, Jinghui Niu  wrote:
> Hi, I wonder if there is any recommendation or best practice on choosing
> between
> hybrid_property
>
> and
> hybrid_method
> ,
> other than they hybrid_method can take arguments? If I use the hybrid_method
> only throughout, without giving it a argument more than self, doesn't it
> equal to using hybrid_property? Thanks.

It's the same trade-off as using normal python properties vs methods.
For properties, the underlying code is executed when the attribute is
accessed, whereas methods are executed when they are *called*. For
example, if you had this:

class Interval(Base):
__tablename__ = 'interval'

id = Column(Integer, primary_key=True)
start = Column(Integer, nullable=False)
end = Column(Integer, nullable=False)

def __init__(self, start, end):
self.start = start
self.end = end

@hybrid_property
def length_property(self):
return self.end - self.start

@hybrid_method
def length_method(self):
return self.end - self.start

...then you could query using the property like this:

session.query(Interval).filter(Interval.length_property > 5)

But the method would have to be used like this:

session.query(Interval).filter(Interval.length_method() > 5)

It's up to you which you prefer.

Hope that helps,

Simon

-- 
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.