[sqlalchemy] Re: polymorphic question
hi, i'm back to the cane field... do your ABC tests all use select_mapper ? ticket 795 revealed that totally basic ABC loading was broken if you're using secondary loads of the remaining attributes (which is the default behavior when you dont specify select_mapper). u mean mapper's select_table=..? it's allways used because of polymorphism. today i tried those ABC things, found 2 issues: - r3449 introduces some memory leak - r3646 introduces some forever-recursion, goes like: File other/expression.py, line 355, in module p2 = session.query( Person).filter_by( name= 'pesho').first() File /home/az/src/hor-trunk/sqlalchemy/orm/query.py, line 595, in first ret = list(self[0:1]) File /home/az/src/hor-trunk/sqlalchemy/orm/query.py, line 620, in __iter__ context = self._compile_context() File /home/az/src/hor-trunk/sqlalchemy/orm/query.py, line 873, in _compile_context value.setup(context) File /home/az/src/hor-trunk/sqlalchemy/orm/interfaces.py, line 483, in setup self._get_context_strategy(querycontext).setup_query(querycontext, **kwargs) File /home/az/src/hor-trunk/sqlalchemy/orm/strategies.py, line 553, in setup_query value.setup(context, parentclauses=clauses, parentmapper=self.select_mapper) File /home/az/src/hor-trunk/sqlalchemy/orm/interfaces.py, line 483, in setup self._get_context_strategy(querycontext).setup_query(querycontext, **kwargs) File /home/az/src/hor-trunk/sqlalchemy/orm/strategies.py, line 553, in setup_query value.setup(context, parentclauses=clauses, parentmapper=self.select_mapper) ... last two repeated ... more details tomorrow ciao svilen --~--~-~--~~~---~--~~ 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: polymorphic question
On Friday 28 September 2007 01:14:32 Michael Bayer wrote: On Sep 27, 2007, at 3:53 PM, [EMAIL PROTECTED] wrote: i know in 0.4 one can request a polymorphic request to be automaticaly split into multiple per-subtype requests. i've no idea how this compares +/- to the huge union/outerjoin that gives all in one long shot. my question is.. can this mechanism/approach be used somehow for (semi) automatic vertical loading, i.e. instead of loading all items in all rows, load only some items normaly while (pre)loading some specific columns in whole in one separate shot? say there is a table X having a,b,c..p,q. So i do a plain row query over X, getting a,b,c,d per row, and request the p and q columns (pre)loaded whole (or partial as per some limit). i imagine this to be useful to avoid zillions of eagerloads/joins etc (when the columns in question are links to somewhere). but i might be wrong... - i've no idea how the eagerloading scales. Any arguments pro/con? if youre talking about just one table X, deferred columns will hold off the loading of those columns until they are accessed. as far as the joined tables, polymorphic_fetch=deferred will leave those to be loaded when those attributes are first accessed. that's as well as I understand your question so far mmm no, i'm not asking that. is there any available mechanism to load a query by columns instead of by rows. that is split a query verticaly. like paginate verticaly and not just horizontaly. Think a table with rows and many columns. usualy query yields full rows. i want to split the query into several, each having a number (=1) of columns of the whole thing, all under same filtering, one being the leading one, others loaded per request, in big chunks). nevermind, it won't be hard to make anyway, once i know exacty what i need --~--~-~--~~~---~--~~ 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: polymorphic question
On Sep 27, 2007, at 3:53 PM, [EMAIL PROTECTED] wrote: i know in 0.4 one can request a polymorphic request to be automaticaly split into multiple per-subtype requests. i've no idea how this compares +/- to the huge union/outerjoin that gives all in one long shot. my question is.. can this mechanism/approach be used somehow for (semi) automatic vertical loading, i.e. instead of loading all items in all rows, load only some items normaly while (pre)loading some specific columns in whole in one separate shot? say there is a table X having a,b,c..p,q. So i do a plain row query over X, getting a,b,c,d per row, and request the p and q columns (pre)loaded whole (or partial as per some limit). i imagine this to be useful to avoid zillions of eagerloads/joins etc (when the columns in question are links to somewhere). but i might be wrong... - i've no idea how the eagerloading scales. Any arguments pro/con? if youre talking about just one table X, deferred columns will hold off the loading of those columns until they are accessed. as far as the joined tables, polymorphic_fetch=deferred will leave those to be loaded when those attributes are first accessed. that's as well as I understand your question so far --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
