On Apr 25, 2007, at 3:52 PM, Gaetan de Menten wrote:

> It's better with the attachments (the actual patch and a small
> demonstration/test file)...
>
> On 4/25/07, Gaetan de Menten <[EMAIL PROTECTED]> wrote:
>> Ok, I'm quite a bit stubborn at times, so I implemented this the  
>> way I
>> thought because I think it makes much more sense this way.
>>
>> Attached is an experimental (as usual) patch to add a
>> StatementProperty, so that you can define stuff like:
>>
>> mapper(Tag, tags_table, properties={
>>     'query_score': StatementProperty((tags_table.c.score1 *
>> tags_table.c.score2).label('tag_score'), Float()),
>> })
>>
>> or even:
>>
>> user_score = select([func.sum(tags_table.c.score1 *
>>                               tags_table.c.score2)],
>>                     tags_table.c.user_id == users_table.c.id,
>>                     scalar=True).label('user_score')
>>
>> mapper(User, users_table, properties={
>>     'tags': relation(Tag, backref='user', lazy=False),
>>     'query_score': StatementProperty(user_score, Float()),
>> })
>>
>> I don't see what's wrong with this approach so far. As always, I  
>> might
>> not see the big picture... I just hope this will be useful in some
>> way, even if it's not what you envisioned.

OK well thats not bad. also im glad you are getting familiarized with  
ORM internals, since there are very few who have ventured in there so  
far.  But here some bigger picture things:

        - you have an aggregate function there.  wheres the GROUP BY ? not  
just of the main table's columns but any other columns named for  
eager loads.
        - it only works for scalars.  what about statements that return lists ?
        - it doesnt figure out any kind of join conditions to the parent  
table.  what happens when a polymorphically loading mapper tries to  
use it  (or any of the other myriad bizarro things that happen with  
inheritance)?
        - the biggest picture not here - its read only !
        - we already have a way to do the above - map to a select statement,  
thereby forcing the user to figure out GROUP BY, polymorphic loading,  
etc., also produces an encapsulated statement which eager loaders,  
LIMIT/OFFSET etc. criterion can be more readily tacked onto.

Since you have built upon interfaces that I consider to be public so  
this is definitely at least a decent recipe.  im not sold on it as a  
core feature though since its scope is too narrow compared to what  
people will expect from 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to