On 4/26/07, Michael Bayer <[EMAIL PROTECTED]> wrote: > 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....
Well, for me, everything which is called often enough should be factored in the class as a property. The problem being that if you use a python property, you'd have an extremely inefficient code (to compute one aggregate method, you'd have to load all related instances, and so on...). > within the SA philosophy at least. Ok, I'll shut-up after this mail... I can't argue with that. ;-) > >> - 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. I'll try this (add_column) route. The problem with this approach is that I fear it won't be easy to have those additional columns still available as lazy load. Though I haven't thought much about this option yet, so that might prove easier than I think. > 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()... Almost... I would have wanted to not even have to declare alternate mappers, only all the possible "additional" (aggregate) columns. And at query time say: fetch this and that "column" (in addition to the main query) and not those others (which would still be available as lazy properties). > 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. FYI, postgres eats my example just fine. > 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). Ok, I'll try to implement that in my own private layer on top of Elixir, then *if* that's not too invasive I'll either include it in Elixir (if nobody disagrees there) or post it as a recipe for SQLAlchemy. -- 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 -~----------~----~----~----~------~----~------~--~---
