On 4/26/07, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
>
> 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's unneeded in my example, and for cases where this would be needed,
I think we could easily enhance the StatementProperty so that you can
add anything to the parent query: join conditions, etc...
> - it only works for scalars. what about statements that return lists
> ?
Yeah that's a limitation of the approach, but I think it's ok. Maybe
rename the thing to ScalarProperty to make it more obvious?
> - 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)?
Ok, that might be a problem. Honestly, I have a pretty narrow
knowledge (and fuzzy understanding) of the internals of that whole
polymorphic inheritance. But wouldn't it be possible to factor out
what is done in the relation loaders. The problems ought to be the
same, right? And it'd also solve your list statement complaint above.
From my understanding, it's "just" the last part (ie to create an
instance out of the scalar(s)) which needs to be skipped). In fact,
this was how I originally intended to implement the thing but that
code seemed too complex to tap into to make my demonstration patch, so
I rather took the ColumnProperty code as a base ;-).
My point was and still is (I just realized I haven't said it clearly
yet): I don't get why it would be preferable to go through the trouble
of creating instances and proxies just to go through them and only
ever use them as scalars, when one could (or at least, I'm convinced
one could) simply skip the instance creation step.
> - the biggest picture not here - its read only !
It's obviously meant to be that way... So I don't see a problem here.
We might want to add an exception when people try to change it, but
that shouldn't be too hard. Besides, I don't see how the
association_proxy approach would make it any different.
> - 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.
No, this doesn't suit my needs. I need that particular property to be
deferrable. As I said, I got several of them and, for each query, I
can need any combination of them. Even though my patch doesn't include
the code to do it, with "my" approach, I think it's possible to do it,
unlike with the "map to a select statement" approach.
>
> 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.
>
--
Gaëtan de Menten
http://openhex.org
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
