Keep in mind that the method on your Bar class:
def all_foo(self):
foo_query.all()
will return a raw *list* of Foo objects. If you append more Foo
objects to it, they won't be seen by SQLAlchemy's session, thus not
being commited. Although, if you have set on your mapper:
properties={
'all_foo': relation(Foo)
})
"bar.all_foo" will return an InstrumentedList object, which somehow
knows it's related to Bar and any new objects appended in here will be
seen by SA's session, thus changes will be commited.
(SA gurus, correct me if I'm wrong)
This behavior might help you make a choice on your lazy strategy.
Regards,
Alex
2009/9/15 Wolodja Wentland <wentl...@cl.uni-heidelberg.de>:
> On Thu, Sep 10, 2009 at 23:27 +0200, Wolodja Wentland wrote:
>> Hi all,
>>
>> I observed that if I define a relation (foo_query) as lazy='dynamic' and
>> access all referenced entities with foo_query.all() that the query will
>> be executed every time i access it. That is not a big surprise ;-)
>>
>> In a library I am writing i want to provide methods that allow
>> pre-filtering of referenced entities and also on that provides access to
>> all entities. I am wondering if it is better/faster/.. to define *two*
>> relations for filtering and accessing all entities respectively.
>>
>> I can't really decide between the following two approaches and would be
>> happy if someone could provide some tips:
>>
>> Approach 1
>> ----------
>>
>> Class Bar(object):
>>
>> def all_foo(self):
>> foo_query.all()
>>
>> def foo_startwith(self, search_string):
>> foo.query.filter(tbl.c.col.like('%s%%'% ...))
>>
>> mapper(Bar,
>> ...
>> properties={
>> 'foo_query': relation(Foo, lazy='dynamic')
>> })
>>
>> Approach 2
>> ----------
>>
>> Class Bar(object):
>>
>> def foo_startwith(self, search_string):
>> foo.query.filter(tbl.c.col.like('%s%%'% ...))
>>
>> mapper(Bar,
>> ...
>> properties={
>> 'all_foo': relation(Foo)
>> })
>> properties={
>> 'foo_query': relation(Foo, lazy='dynamic')
>> })
>>
>> Which one is faster? Does it make a difference, given the
>> optimisation/cache in the database? Will it just mean more bloat in the
>> mapper definition?
>
> Nobody can help with the decision?
>
> Wolodja Wentland
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkqvts4ACgkQc5LrxXrbkwjC+wCfeyV3pLGq2ZGxn3ZNYmmc3cLK
> M9cAniKtnGlxymFccEiUENy7UzOrFlFk
> =ydwe
> -----END PGP SIGNATURE-----
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
