[sqlalchemy] Re: Bug? Polymorphic inheritance 100 times slower
Thanks for the explanation! The root of the issue is now very clear. But are you saying that this is intended behavior? Was I wrong in trying to use the session as an object cache? Now onto a possible solution or workaround... Please forgive me if the following does not make sense, but would it be possible to store our object in the identity map under a second key: (Person, (2,))? Then the Person mapper would find it and we'd avoid having to generate a DB query. Is there any technical issue that would prevent the same object from being registered under different keys in the identity map? Cheers! On Jul 15, 11:47 pm, Michael Bayer [EMAIL PROTECTED] wrote: the non polymorphic search is against the Person mapper; it recieves id 1 and looks in the identity map for (Person, (1,)) and locates the existing object immediately. For id 2, it also looks in the map for (Person, (2,)), and finds nothing; it must issue a query which returns the fact that id 2 is of type employee, creates the proper identity key of (Employee, (2,)), and returns the value from the identity map. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Bug? Polymorphic inheritance 100 times slower
On Monday 16 July 2007 09:59:41 Yves-Eric wrote: Thanks for the explanation! The root of the issue is now very clear. But are you saying that this is intended behavior? Was I wrong in trying to use the session as an object cache? Now onto a possible solution or workaround... Please forgive me if the following does not make sense, but would it be possible to store our object in the identity map under a second key: (Person, (2,))? Then the Person mapper would find it and we'd avoid having to generate a DB query. Is there any technical issue that would prevent the same object from being registered under different keys in the identity map? i guess unless u are having another mixed-up-id's pseudo-concrete-inheritance case, it's okay. More, any object X inheriting C which inherits B which inherits A may get registered as all those (X,id), C(id), B(id), A(id) - as long as the id's are really same. But this is what _could_ be done, not what _should_ be done... On Jul 15, 11:47 pm, Michael Bayer [EMAIL PROTECTED] wrote: the non polymorphic search is against the Person mapper; it recieves id 1 and looks in the identity map for (Person, (1,)) and locates the existing object immediately. For id 2, it also looks in the map for (Person, (2,)), and finds nothing; it must issue a query which returns the fact that id 2 is of type employee, creates the proper identity key of (Employee, (2,)), and returns the value from the identity map. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] eagerloading stops due to recursion check
Hello
I found conditions when eagerloading does not work because of
recursion check in setup_query (strategy.py) method.
Say I have classes A,B,C
and
A_mapper has properties a_to_b_property1, a_to_b_property2,
B_mapper has property b_to_c_property.
When I make something like
query(A).options(eagerload('a_to_b_property1'),eagerload('a_to_b_property1.b_to_c_property'),eagerload('a_to_b_property2')).get(...)
After processing two first eagerload properties, B_mapper is in
recursion stack
and a_to_b_property2 cannot modify query statement.
Any other way to check recursion detection?
Thanks
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: SQLAlchemy 0.3.9 Released
on the generative line: - how would i prepack a select (or some other filtering) and give it to a query() _later_? e.g. i have some table.c.type == 'person', and i want to apply to several queries? i can store the expression, doing query.select(expr) each time. Any other way? e.g. store a select([expr])? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: transaction deadlock in sqlalchemy connection transactions
On Jul 15, 2007, at 11:19 PM, SamDonaldson wrote: Say I used the threadlocal strategy here. What would the effect of the following nested calls since I use a decorator? Would it detect and use the same connection and the same top level transaction? engine.begin() do something engine.commit() else engine.rollback() yes as long as everyone uses engine.execute(), statement.execute(), or engine.contextual_connect(), they make use of the same connection within the same thread. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: MapperExtension ... is there a do_after_everything_else() hook?
On Jul 15, 11:47 am, [EMAIL PROTECTED] wrote: thought it might. In my little MCV world, it's part of M, not C or V and I wanted to keep it that way as much as possible. It still is, just not in SA. i have similar thing into the M/odel, but it is pre_save(), not after_load(). So it's easier, and done by the sa-managing wrapper. Though i'm thinking that one day i may need some after_load() - it is symmetrical to pre-save, and these things go in pairs... Heh! Oh yes, good thought, and I do some pre_save() massaging as well. But now that you mention it, it's fairly symmetrical conceptually having both parts in my own Model code and not in SA's code. Having Turbogears' model.py *is* after all, part of the Model. -Paul --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: eagerloading stops due to recursion check
On Jul 16, 2007, at 7:17 AM, non-alex wrote:
Hello
I found conditions when eagerloading does not work because of
recursion check in setup_query (strategy.py) method.
Say I have classes A,B,C
and
A_mapper has properties a_to_b_property1, a_to_b_property2,
B_mapper has property b_to_c_property.
When I make something like
query(A).options(eagerload('a_to_b_property1'),eagerload
('a_to_b_property1.b_to_c_property'),eagerload
('a_to_b_property2')).get(...)
After processing two first eagerload properties, B_mapper is in
recursion stack
and a_to_b_property2 cannot modify query statement.
Any other way to check recursion detection?
another way to checkbecause why ? you want to not use those
eagerload() options in the first place ? not sure what youre asking
for here.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Problem with sqlalchemy and mysql
On Jul 15, 2007, at 7:21 PM, SamDonaldson wrote: I haven't done any research on the mysql end yet but my question is, why not disable the wait_timeout option on the mysql end to avoid such connection closing from the server side. Wouldn't this problem go away all together? Why would you ever want to close idle connections in such a way? If anybody knows how to do this then let me know on mysql 5.0 absolutely, setting wait_timeout is another way to go here. just that its less convenient to ensure that all mysql dbs' which run with your code have this setting made. the expenditure of pool_recycle is also next to nil, a little reconnect every few hours is not expensive at all. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Problem with sqlalchemy and mysql
On Jul 15, 2007, at 6:33 PM, SamDonaldson wrote: Ok. This did not work and I dug this thread where you had a discussion on this. It seems like this was fixed in sqlalchemy and you were calling rollback twice which caused this issue. http://groups.google.com/group/sqlalchemy/browse_thread/thread/ 9412808e695168ea/c31f5c967c135be0?lnk=raot Unfortunately the symptoms are the same but I wanted to run by some connection code that I'm using to get a connection and start a transaction to check whether this could potentially cause any issues. Note that this decorator is called on any method running sql. It basically wraps the function by creating the connection and then closing it. that issue would occur if youre accessing mysql in several threads simultaneously (and also, if that exact issue still existed which it does not). you said that this problem occurs after a few hours of idle time, which is the opposite condition. are you observing the issue immediately when you use a threaded load test ? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Bug? Polymorphic inheritance 100 times slower
On Jul 16, 2007, at 2:59 AM, Yves-Eric wrote: Thanks for the explanation! The root of the issue is now very clear. But are you saying that this is intended behavior? Was I wrong in trying to use the session as an object cache? this is why im extremely hesitant to call the session a cache. its only slightly cachelike becuase in most cases it doesnt prevent SQL from being issued. Now onto a possible solution or workaround... Please forgive me if the following does not make sense, but would it be possible to store our object in the identity map under a second key: (Person, (2,))? Then the Person mapper would find it and we'd avoid having to generate a DB query. Is there any technical issue that would prevent the same object from being registered under different keys in the identity map? There are some kinds of inheritance where both Person/2 and Employee/ 2 exist distinctly, namely the concrete inheritance svil mentions. so that makes me less comfortable with that approach. it does seem like you can in many cases define the set of identities for an entire class hierarchy a/b/c/d/e... against the root mapper only, i.e. just (A, (id,)).its something to look into (changing the key to represent based on the root class in all non-concrete cases, not storing two keys). if you were so inclined you could also add this you can build this yourself and wire it in to query.get() using a MapperExtension that implements get() (and populates the cache during populate_instance(), perhaps...we will have a better hook for post-load operations in 0.4). --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: SQLAlchemy 0.3.9 Released
On Jul 16, 2007, at 10:12 AM, svilen wrote: On Monday 16 July 2007 16:54:01 Michael Bayer wrote: On Jul 16, 2007, at 9:20 AM, svilen wrote: on the generative line: - how would i prepack a select (or some other filtering) and give it to a query() _later_? e.g. i have some table.c.type == 'person', and i want to apply to several queries? i can store the expression, doing query.select(expr) each time. Any other way? e.g. store a select([expr])? you can store the select(), or the where clause, or the select ().compile() object, or the query object itself since its generative. which do you prefer ? hmmm. query is not available at that time. so far i store the expression only, although that is missing things like fold_equivalents=True. in the case of polymorphic outerjoins, i get all the id' columns of all joined tables (5 columns something.id for 5 level inheritance). Any way to get rid of them? well if you select() from it and fold_equivalents, yes.but using just the join by itself, i think the code in 0.4 should be *really* smart about not tripping over those at this point, no ? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: eagerloading stops due to recursion check
Sorry, i'll try to be precise. table_A contains two distinct foreign keys to table_B, table_B contains one foreign key to table_C mapped classes are A, B, C. mapper_A contains two corresponding properties a_to_b_property1, a_to_b_property2 to class B. mapper_B contains property b_to_c_property I cannot eagerload all three properties in session.query(A)... ! look at this lines (strategies.py, setup_query): 464if self.mapper in context.recursion_stack: 465return 466else: 467context.recursion_stack.add(self.parent) After processing eagerload property 'a_to_b_property1. b_to_c_property', context.recursion_stack contains B_mapper (as a parent of b_to_c_property) - line 467 so 'a_to_b_property2' just skipped - line 464. I want to load all this relations in one query. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Bug? Polymorphic inheritance 100 times slower
On Monday 16 July 2007 17:08:08 Michael Bayer wrote: On Jul 16, 2007, at 2:59 AM, Yves-Eric wrote: Thanks for the explanation! The root of the issue is now very clear. But are you saying that this is intended behavior? Was I wrong in trying to use the session as an object cache? this is why im extremely hesitant to call the session a cache. its only slightly cachelike becuase in most cases it doesnt prevent SQL from being issued. Now onto a possible solution or workaround... Please forgive me if the following does not make sense, but would it be possible to store our object in the identity map under a second key: (Person, (2,))? Then the Person mapper would find it and we'd avoid having to generate a DB query. Is there any technical issue that would prevent the same object from being registered under different keys in the identity map? There are some kinds of inheritance where both Person/2 and Employee/ 2 exist distinctly, namely the concrete inheritance svil mentions. so that makes me less comfortable with that approach. it does seem like you can in many cases define the set of identities for an entire class hierarchy a/b/c/d/e... against the root mapper only, i.e. just (A, (id,)).its something to look into (changing the key to represent based on the root class in all non-concrete cases, not storing two keys). i think it is not a problem to store as many keys as there are identical levels in polymorphism/inheritance as long as this is synchronized with type of inheritance. i.e. joined-table inheritance chains (and single table maybe) are ok as is, anything concrete-table in between changes the game. As for the concrete, i think it can be done same as with polymorphism - storing composite keys (type,id) where just keys are ambigious. but i bet noone has ever wanted mixed inheritance, no? (:-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Bug? Polymorphic inheritance 100 times slower
On Jul 16, 2007, at 10:45 AM, svilen wrote: i think it is not a problem to store as many keys as there are identical levels in polymorphism/inheritance as long as this is synchronized with type of inheritance. i.e. joined-table inheritance chains (and single table maybe) are ok as is, anything concrete-table in between changes the game. As for the concrete, i think it can be done same as with polymorphism - storing composite keys (type,id) where just keys are ambigious. but i bet noone has ever wanted mixed inheritance, no? (:-) well this has been coming up in other ways lately too. if you map inheritance like this (forgive my entirely made up table syntax): table a ( id primary key ) table b( id primary key a_id foreign key a.id ) SA makes the primary key of B to be (a.id, b.id), since theres a pk in both tables...you have to call get() as get(1,2). this stems from just, i was trying to put as few opinions as possible anywhere. but this is silly. unless we were supporting some kind of inheritance where B1 would be (1,1) and B2 would be (1, 2), i.e. sharing a row of A between two instances, theres no reason the primary key shouldnt be just (a.id). but then, maybe someone does want to do that ? we always wanted to allow as much hackery as possible. what i think i might try to do today, in 0.4, is to calculate the primary key columns of a mapper against its bottommost inherited mapper, when concrete is not present (as usual, concrete cases get thrown by the wayside for now). and *then*, the identity_key would also get created against the bottommost mapper located in this process as well (so yes, (Person, (x,)) in all cases). that would actually fix a lot of thingsin most cases ppl wouldnt have to be calling get(x,y,z) or assembling distinct primary keys to achieve it. if they do want the hackery mentioned above, *then* they can put an explicit primary_key on their mapper for that. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: eagerloading stops due to recursion check
On Jul 16, 2007, at 10:41 AM, non-alex wrote: I want to load all this relations in one query. yeah...we dont currently support eager loading across cyclical relationships. I have tried to make this work and in fact its not so hard to formulate the query (since eager loading creates aliases anyway), but it ran into some snags on the row-receiving side when it was trying to tell one level of table from another and trying not to go into an endless loop. which is not to say its impossible, but just its a lot more complex than it seems (not to mention you have to explicitly set a depth parameter on your query so it knows how deep youd like to go). feel free to open an enhancement ticket for this since id like to get it in there eventually, hopefully within the 0.4 series. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: eagerloading stops due to recursion check
On 16 июл, 19:26, Michael Bayer [EMAIL PROTECTED] wrote: On Jul 16, 2007, at 10:41 AM, non-alex wrote: yeah...we dont currently support eager loading across cyclical relationships. Well, i thought that my example does not concern cyclical relations. In my case, relation paths are A-(foreign key1)-B-C A-(foreign key2)-B and not, say, A-B-A. So depth parameter not needed. But If you do not object to alter eagerloading, including cyclical relations, I'll wait the new version. One more question about 0.4 version. I want to refresh attributes of large collection of objects. Session refresh/expire/load will be too slow - many queries. Session.clear() seems to be overkill - ALL objects removed from session -right? You discouraged to use always_refresh (I agree with it). I found this 'unofficial' recipe in mailing list: result = query._select_statement(query.compile(),populate_existing=True) How can I do massive refresh by one query (including eager loading) in 0.4 version? In some thread, you said that --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: eagerloading stops due to recursion check
On Jul 16, 2007, at 12:49 PM, non-alex wrote: On 16 июл, 19:26, Michael Bayer [EMAIL PROTECTED] wrote: On Jul 16, 2007, at 10:41 AM, non-alex wrote: yeah...we dont currently support eager loading across cyclical relationships. Well, i thought that my example does not concern cyclical relations. In my case, relation paths are A-(foreign key1)-B-C A-(foreign key2)-B and not, say, A-B-A. So depth parameter not needed. But If you do not object to alter eagerloading, including cyclical relations, I'll wait the new version. Oh i see, theres no cycle. well, thats a bug. what modification did you want to make ? One more question about 0.4 version. I want to refresh attributes of large collection of objects. Session refresh/expire/load will be too slow - many queries. Session.clear() seems to be overkill - ALL objects removed from session -right? You discouraged to use always_refresh (I agree with it). I found this 'unofficial' recipe in mailing list: result = query._select_statement(query.compile(),populate_existing=True) How can I do massive refresh by one query (including eager loading) in 0.4 version? i think i had planned to make populate_existing an offical option, a la: query.populate_existing().filter(...).all() but thanks for reminding me. it would be helpful if you could add tickets for both issues, milestone 0.4. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] lazy = None behavior help...
Greetings!
I have a situation where I would like to be able to switch between an
implicit eager load and an explicit no load of a series of related
objects. I've set up a couple of mappers for the object in question
(Entry in the code below), the primary mapper keeps uses a lazy load
(lazy = True) and the alternate uses no load (lazy = None). However,
I discovered that an object retrieved with the no load mapper,
performs a lazy load when attempting to explicitly add elements to the
relation list. I've included test code and the relevant log statements
below:
test code:
import sqlalchemy.ext.sessioncontext as sqlsessioncontext
import sqlalchemy as sql
import logging
#logging
file = logging.FileHandler(__name__+'.log')
file.setLevel(logging.DEBUG)
console = logging.StreamHandler()
console.setLevel(logging.INFO)
logging.getLogger(sqlalchemy).addHandler(console)
logging.getLogger(sqlalchemy).addHandler(file)
logging.getLogger(sqlalchemy).setLevel(logging.DEBUG)
#create an in memory db
engine = sql.create_engine(sqlite:///:memory:)
metadata = sql.MetaData(engine=engine)
sessionContext =
sqlsessioncontext.SessionContext(lambda:sql.create_session(engine))
#class definitions
class Entry(object):
def __init__(self, id = None, title = None):
if id:
self.id = id
self.title = title
table = sql.Table('entry', metadata,
sql.Column('id', sql.Integer(), primary_key=True),
sql.Column('title', sql.String(), primary_key=True)
)
class TagAssoc(object):
def __init__(self, entry = None, tag = None):
self.entry = entry
self.tag = tag
table = sql.Table('entry_to_tag', metadata,
sql.Column('tag_id', sql.Integer(),
sql.ForeignKey('tag.id',onupdate='CASCADE',ondelete='CASCADE'),
nullable=False),
sql.Column('entry_id',sql.Integer(),
sql.ForeignKey('entry.id',onupdate='CASCADE',ondelete='CASCADE'),
nullable=False)
)
class Tag(object):
def __init__(self, id = None, name = None):
if id:
self.id = id
self.name = name
table = sql.Table('tag', metadata,
sql.Column('id', sql.Integer(), primary_key=True),
sql.Column('name', sql.String(), primary_key=True)
)
metadata.create_all()
#entry mappers
loading_entry_mapper = sql.mapper(
Entry,
Entry.table,
properties = {
'tagAssocs' : sql.relation(TagAssoc, lazy = True,
cascade=all, delete-orphan)
}
)
non_loading_entry_mapper = sql.mapper(
Entry,
Entry.table,
properties = {
'tagAssocs' : sql.relation(TagAssoc, lazy = None,
cascade=all, delete-orphan)
},
non_primary = True
)
tag_assoc_mapper = sql.mapper(
TagAssoc,
TagAssoc.table,
primary_key=[TagAssoc.table.c.entry_id, TagAssoc.table.c.tag_id],
[EMAIL PROTECTED]
properties = {
'tag' : sql.relation(Tag, lazy=False, uselist=False),
'entry' : sql.relation(Entry,lazy=False, uselist=False)
}
)
tag_mapper = sql.mapper(
Tag,
Tag.table
)
#save test data
session = sessionContext.current
entry1 = Entry(id = 1, title=entry1)
session.save(entry1)
session.flush()
tag1 = Tag(id = 1, name=tag1)
session.save(tag1)
session.flush()
assoc1 = TagAssoc(entry1, tag1)
entry1.tagAssocs.append(assoc1)
session.save(assoc1)
session.flush()
session.close()
#retrieve the entry using the non-loading mapper
session = sessionContext.current
statement = sql.select([Entry.table])
entries = session.query(non_loading_entry_mapper).select(statement)
#use a simple case: set tagAssocs to a blank list. This shouldn't
cause an eager load, should it?
entries[0].tagAssocs = []
The relevant log section:
SELECT entry.id AS entry_id, entry.title AS entry_title
FROM entry
[]
instances()
Row (1, u'entry1')
Connection pysqlite2.dbapi2.Connection object at 0x00DECDA0 being
returned to pool
(Entry|entry|non-primary) _instance(): identity key (class
'__main__.Entry', (1, u'entry1'), None) not in session[]
(Entry|entry|non-primary) _instance(): created new instance
[EMAIL PROTECTED] identity (class '__main__.Entry', (1, u'entry1'),
None)
populating [EMAIL PROTECTED] with RowProxy/id
populating [EMAIL PROTECTED] with RowProxy/title
#not expected behavior for an attribute with no
load.###
Executing lazy callable on [EMAIL PROTECTED]
lazy load attribute tagAssocs on instance [EMAIL PROTECTED]
Connection pysqlite2.dbapi2.Connection object at 0x00DECDA0 checked
out from pool
SELECT anon_f75b.id AS anon_f75b_id, anon_f75b.title AS
anon_f75b_title, anon_d876.id AS anon_d876_id, anon_d876.name AS
anon_d876_name, entry_to_tag.entry_id AS entry_to_tag_entry_id,
entry_to_tag.tag_id AS entry_to_tag_tag_id
FROM entry_to_tag LEFT OUTER JOIN entry AS anon_f75b ON anon_f75b.id =
entry_to_tag.entry_id LEFT OUTER JOIN tag AS anon_d876 ON anon_d876.id
= entry_to_tag.tag_id
WHERE ? = entry_to_tag.entry_id ORDER BY entry_to_tag.oid,
anon_f75b.oid, anon_d876.oid
[1]
instances()
Row (1, u'entry1', 1, u'tag1', 1, 1)
So,
[sqlalchemy] Re: lazy = None behavior help...
(1, u'entry1', 1, u'tag1', 1, 1)
So, what am I doing wrong?
my impression, without trying out the example to verify, is youre
using non_primary mappers to affect loading behavior. use
query.options(noload('propname')) instead.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: lazy = None behavior help...
On Jul 16, 2007, at 5:25 PM, Cory Smith wrote: That is exactly what I'm doing. I take it that mappers do not affect the loading? non-primary mappers have no effect on the properties attached to classes. only the primary mapper and the query which loaded an instance has an opinion on that. theres not *too* many use cases for non primary mappers and id eliminate the rest of them if i could. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: lazy = None behavior help...
Fair enough. I don't remember that in docs. Did I miss a section, or is this too obscure for the general usage? (Like the time I decided to override the object.__hash__ to work off the primary key? Made object saving a real treat. couldn't figure out why I always had orphaned objects in the session.) -c On 7/16/07, Michael Bayer [EMAIL PROTECTED] wrote: On Jul 16, 2007, at 5:25 PM, Cory Smith wrote: That is exactly what I'm doing. I take it that mappers do not affect the loading? non-primary mappers have no effect on the properties attached to classes. only the primary mapper and the query which loaded an instance has an opinion on that. theres not *too* many use cases for non primary mappers and id eliminate the rest of them if i could. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: lazy = None behavior help...
On Jul 16, 2007, at 6:23 PM, Cory Smith wrote: Fair enough. I don't remember that in docs. Did I miss a section, or is this too obscure for the general usage? its only obscure because i think non_primary mappers are not *too* common, but their behavior should be more well defined in the docs (that they dont want to deal with attributes is a big one) (Like the time I decided to override the object.__hash__ to work off the primary key? Made object saving a real treat. couldn't figure out why I always had orphaned objects in the session.) ahhm ive never tried thatwe rely on a lot of set() stuff so yeah, thats another good one to document (or maybe we can find a way to work around it) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Jython and sqlalchemy
Hi all, My name is Frank Wierzbicki and I'm the primary maintainer of Jython. We are about to release 2.2, so I've turned my attention to post 2.2 stuff. I tried our 2.3 alpha with sqlalchemy against mysql and found that it wasn't that hard to get it to work for a (very) simple test. This is by no means complete or even good, but I am keeping the code here: http://jython.svn.sourceforge.net/svnroot/jython/trunk/sandbox/wierzbicki/sqlalchemy/ The three files are a simple test (sqla.py), a monkey-patched version of database/mysql.py (mysql.py) and the svn diff as of today (mysql.diff) so I can keep track of the changes I made to get things to work. mysql.py can be pasted on top of the real one, then you can run jython (latest from the 2.3 branch) and it works, at least on my machine :) Obviously patching mysql.py might not be the way it should really be designed and this was just enough change to get my simple test to work, but I thought I would share and see what people think about getting sqlalchemy to work from Jython. -Frank --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Jython and sqlalchemy
hey frank - awesome ! i had tried Jython a little bit but had probs getting its 2.3 support happening. glad to hear its able to import sqlalchemy. this does raise an issue which has come up a few times, which is the best strategy to break up our dialects to support a common database among different drivers. We do have an ad-hoc approach to this in mssql.py and its been suggested that we might want to break up the system to support things like mxODBC. I think the approach we take would wind up having urls like jdbc:mysql://url and such, breaking up dialects to be two distinct levels. anyway, we've had our eye on someday having Jython working with SA all the way since the beginning, so whatever I can do to help let me know, or stop by on #sqlalchemy on freenode. - mike On Jul 16, 2007, at 11:19 PM, [EMAIL PROTECTED] wrote: Hi all, My name is Frank Wierzbicki and I'm the primary maintainer of Jython. We are about to release 2.2, so I've turned my attention to post 2.2 stuff. I tried our 2.3 alpha with sqlalchemy against mysql and found that it wasn't that hard to get it to work for a (very) simple test. This is by no means complete or even good, but I am keeping the code here: http://jython.svn.sourceforge.net/svnroot/jython/trunk/ sandbox/wierzbicki/sqlalchemy/ The three files are a simple test (sqla.py), a monkey-patched version of database/mysql.py (mysql.py) and the svn diff as of today (mysql.diff) so I can keep track of the changes I made to get things to work. mysql.py can be pasted on top of the real one, then you can run jython (latest from the 2.3 branch) and it works, at least on my machine :) Obviously patching mysql.py might not be the way it should really be designed and this was just enough change to get my simple test to work, but I thought I would share and see what people think about getting sqlalchemy to work from Jython. -Frank --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
