yeah, its committed right now as built in, but its only a handful of lines
of code. if you wanted to bypass it you could call
mapper.select_whereclause() which is what select() calls anyway.
but yah, i think i want to make it optional. i think per-mapper is one
way it might be used; but i think others will want it everywhere. i have
a notion of the way people perceive browser "plugins", or in other
software like blogs..like "mods" or something. theres a whole lot of
behaviors people are wanting now, none of which do i think everyone wants
(even this one, which I thought everyone wanted, youre already looking to
turn it off...)
some mods that we might have are:
- selectresults: adds on-the-fly limit/offset construction based on
array slices/indexes. can be used per-mapper or global.
- refresh-on-insert: some people are wanting to manipulate foreign key
ids on their objects and then have the related objects be present after
a save. can be used per-mapper or global.
- polymorphic: this plugin requires some arguments and will give you a
mapper that returns multiple kinds of arguments based on some columns
in the query. this is per-mapper only.
- paranoid-concurrency: does that "update based on every column being
updated" thing we mentioned.
- assign_mapper: why not have assign_mapper be a mod too. now you
just say mapper(class, table) and it automatically does the
"assign_mapper" thing. people can make all kinds of assign_mapper
plugins.
- lexical structures: someone asked about the sql CASE/WHEN statement.
lets have a plugin that makes that available...this one has nothing to
do with mappers, and its only global. but then maybe this is just a
regular "ext" module.
I would want it to be easy to have these things be per-mapper, or global.
a lot of these are "personal taste" kinds of things that some folks will
just want everywhere, without any hassle. and of course this is all about
people having ways to have all the quirky behaviors they want without my
needing to stick them in the core (and more importantly so I support a
core thats not full of tons of features and paradigms i dont want to
support).
also id want the MapperExtension object to be the primary method to extend
mappers, even though a mod might work with something other than mappers.
so im thinking of a module-based thing that goes in and affixes itself,
but Im not exactly sure how id want it to look. my best guess is like
this:
import sqlalchemy as rdb
install_mods('selectresults', 'casewhen', 'assign_mapper')
which is going to look in sqlalchemy.mods.* for modules and call some
standard function allowing them to install themselves anyway they want to.
you only call install_mods once then its installed globally, repeated
calls to install_mods dont do anything.
on the mapper, heres SelectResults chained to PolyMorphic:
from sqlalchemy import *
from sqlalchemy.mods import SelectResults, PolyMorphic
m = mapper(SomeClass, table, ext=[SelectResults(),
PolyMorphic(SubClassA, SubClassB, rowfunc)])
or maybe, just use an *args to just pick up on MapperExtensions:
m = mapper(SomeClass, sometable, SelectResults(), PolyMorphic(SubClassA,
SubClassB, rowfunc))
as well as on options:
m2 = m.options(SelectResults())
just some pretty random ideas most of which are less than 5 minutes old....
Daniel Miller wrote:
> Michael Bayer wrote:
>> Ive integrated it with the mapper, which is quite a small change, just
>> added to select() (when used with a "where" clause, not if you send it a
>> full Select object) and select_by(). the major thing you lose with this
>> approach is that you cant call len() on a returned result set. I tried
>> having __len()__ implemenet the count() method, but then the internal
>> calls for list(self) cause the __len()__ method to be called, adding an
>> extra query.
>
> I think I read that correctly: you've changed the behavior of
> mapper.select(some_col='val')? If so, how do we get the old behavior?
>
>>
>> ...
>>
>> i might look into having the SelectResults be optional in some way, as
>> im
>> also looking to build up this "stock plugins" catalog idea, maybe this
>> is
>> another candidate for that. they do add a little bit of extra behavior
>> which might be better presented as "heres a plugin that will give you
>> this
>> extra behavior".
>>
>
> The object-relational impedance mismatch makes this type of "optimization"
> great for some use cases while it totally kills others (for example, the
> issues you (Mike) raised in your previous post in this thread). IMHO this
> type of thing should be a plugin as you're suggesting--preferably
> something that could be used selectively on certain queries (pun not
> intended) rather than being applied across the board. Then those who want
> to use it can use it and others will not be bothered by it.
>
> ~ Daniel
>
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
