On Apr 26, 2007, at 4:40 AM, Gaetan de Menten wrote:
> >> - 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. > the function allows the adding of any arbitrary SQL expression. if that expression were just a column somewhere, and not an aggregate, it would be expected that this would be writeable. reasons like this are why the feature as proposed is too narrow. IMO if you are querying things that are read-only, they generally belong more on the Query side of things and not the object-relationship side of things....within the SA philosophy at least. >> - 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. yeah i would just use non_primary mappers and/or Query.select(full select statement)/ Query.add_column(.etc), the "deferred" version would be just a property on the class itself that issues a Query. essentially everything you want is possible here except that the "deferred" option doesnt hook into it the way you want. which almost implies that maybe you just want a new kind of option() that can select a non-primary mapper for a particular class query... query (MyClass).use_mapper(aggregate_mapper).select()... at most, for this feature, it would have to be called "aggregate()" since its pretty limited to that, and take a limited set of criterion in the same way as relation(), and the GROUP BY stuff would have to work since postgres/oracle/etc. require that. the GROUP BY columns would be automatically added during the query process since its basically, "every column we're selecting". the whole query wrapping thing would have to take place too to cleanly tack on other eager loads, limiting criterion and such. i think some things might continue to break when the query is formed this way (particularly inheritance) and we might have to add a disclaimer "oh by the way, you cant do X, Y and Z when you have a non-deferred aggregate() column" if thats the case. the main thing is, all the tools are there to do this already, we're just talking about adding "yet another way to do it" to suit the code looking a certain way, in a way that also has a lot of non-working use cases. plus, just because its not in core, so what ? its a great recipe, maybe extension, we can even add a unit test to ensure the API continues to support it. elixir can have a built-in feature tying to the recipe as well (since elixir is the "convenience" layer with a little more opinion). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
