[sqlalchemy] Re: assign_mapper query methods
I guess it depends how you look at it. To me assign_mapper adds some Query methods and not others; e.g., .select and .count but not .filter . I assume that's because .filter is so new. But in the manual under Generative Query Methods it implies that .select and .filter are parallel; i.e., you can use either one depending on whether you want the results now or you want to modify the query further. With the regular mapper it's easy to switch between the two by merely changing one method name: rslts = ctx.current.query(MyClass).select(...) q = ctx.current.query(MyClass).filter(...) But with assign_mapper they are not parallel and you have to add or delete an otherwise-useless .query() call (useless because it takes no arguments): rslts = MyClass.select(...) q = MyClass.query().filter(...) As the application's needs change, users will frequently have reason to switch between .select style and .filter style.n You've mentioned earlier that you're not fond of Query.select() at all because users confuse it with Table.select(), and recommended .filter(...).list() instead. If people start doing this wholesale there will be a lot of transformations from .select to .filter, and this same issue will come up. At the same time, I share your concern about adding too many methods to the user class, especially since they may someday collide with one of my database columns. I would rather have parallel select/filter than lots of user class methods. I suppose I could just pretend .select() and .count() don't exist, and use .query().select() and .query().filter() and .query().count() instead -- if .query() is going to be documented and supported long term. I can see why it would be a pity to lose .get(). But on the other hand, why should some Query methods be privileged and others not? --Mike On 5/31/07, Michael Bayer [EMAIL PROTECTED] wrote: heres the question. Query gets 10 new methods one day. do we then add 10 methods to assign_mapper() ? must the user class be a total clone of Query ? assign_mapper just bugs me for this reason. hence i like entity.query() better. im not sure which one youre saying you prefer ? On May 31, 5:46 pm, Mike Orr [EMAIL PROTECTED] wrote: What are future plans for the assign_mapper query methods? MyClass.select(...) -- works great. A clear advantage for assign_mapper over the regular mapper. MyClass.filter(...) -- doesn't exist. MyClass.query().filter(...) -- works but is undocumented and requires a convoluted monkeypatch in the source. Not so clear an advantage over the regular mapper because it's so verbose. The third is the one I've found most useful. That way I can have functions that return a Query, and the caller can call .select(), .select(offset=,limit=), or .count() as they wish. -- Mike Orr [EMAIL PROTECTED] -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: assign_mapper query methods
as it turns out, assign_mapper's monkeypatched methods (and they are all monkeypatched, not sure why you singled out query()) dont conflict with mapped properties since those properties get set up subsequent to the assign_mapper call and replace them. however adding new methods to assign_mapper every release does increase the chances of a regular instance variable getting whacked and breaking an application. so i didnt add filter() because i didnt feel like getting all the bug reports from people who have instance variables called filter, and also because my plan was to do away with *all* the select/filter/etc methods and have everything go through query(). because its hard for me to see how query's interface can develop if we have to worry about every new method name conflicting with the full set of instance variable names for all user-defined classes everywhere. but if we dont think its a problem im certainly not going to hold back assign_mapper from what people want it to be, im just putting out the issues there and you all can decide. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: assign_mapper query methods
On Fri, Jun 01, 2007 at 07:17:19AM -0700, Michael Bayer wrote: so i didnt add filter() because i didnt feel like getting all the bug reports from people who have instance variables called filter, and also because my plan was to do away with *all* the select/filter/etc methods and have everything go through query(). Right. I didn't think of that possibility. Do I read that as assign_mapper will die anyway because you have an implicit PITA tag on it already? ;) but if we dont think its a problem im certainly not going to hold back assign_mapper from what people want it to be, im just putting out the issues there and you all can decide. I think I will refrain from using assign_mapper in the future. I'd like to use .filter() because it's great and I'd rather use the explicit mapper syntax instead of the (barely easier) assign_mapper syntax just to be consistent. Sometimes using the assign_mapper because it's simpler but in other places use the mapper methods because they are more powerful doesn't really look consistent. If you asked me: either provide these methods on the assign_mapper, too, or let the assign_mapper die sooner or later. Am I right that we are just talking of john = session.query(User).get_by(name=john) versus john = User.get_by(name=john) here? I think I can live with that. Inserting/creating new objects looks the same with both mapping methods AFAIK. So we are talking about wasting 15 bytes in every query. I'll go waste some bytes then. Cheers Christoph --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: assign_mapper query methods
For what it's worth I personally vote to get rid of all those query methods (except query() itself, of course). On 6/1/07, Michael Bayer [EMAIL PROTECTED] wrote: as it turns out, assign_mapper's monkeypatched methods (and they are all monkeypatched, not sure why you singled out query()) dont conflict with mapped properties since those properties get set up subsequent to the assign_mapper call and replace them. however adding new methods to assign_mapper every release does increase the chances of a regular instance variable getting whacked and breaking an application. so i didnt add filter() because i didnt feel like getting all the bug reports from people who have instance variables called filter, and also because my plan was to do away with *all* the select/filter/etc methods and have everything go through query(). because its hard for me to see how query's interface can develop if we have to worry about every new method name conflicting with the full set of instance variable names for all user-defined classes everywhere. but if we dont think its a problem im certainly not going to hold back assign_mapper from what people want it to be, im just putting out the issues there and you all can decide. -- 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: assign_mapper query methods
On Jun 1, 11:37 am, Christoph Haas [EMAIL PROTECTED] wrote: sooner or later. Am I right that we are just talking of john = session.query(User).get_by(name=john) versus john = User.get_by(name=john) well assign_mapper gives you the *huge* advantage that you can forget about the session in most cases, since its applying a SessionContext to all operations, including construction, etc. thats the reason i find myself using it sometimes, it eliminates the need for all those session.save() operations etc. so User.query().etc is definitely less effort since you dont have to find your session. the elixir crew's +1 on having just query() is compelling since theyre the leading consumers of assignmapper. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: assign_mapper query methods
On 6/1/07, Michael Bayer [EMAIL PROTECTED] wrote: On Jun 1, 11:37 am, Christoph Haas [EMAIL PROTECTED] wrote: sooner or later. Am I right that we are just talking of john = session.query(User).get_by(name=john) versus john = User.get_by(name=john) well assign_mapper gives you the *huge* advantage that you can forget about the session in most cases, since its applying a SessionContext to all operations, including construction, etc. thats the reason i find myself using it sometimes, it eliminates the need for all those session.save() operations etc. so User.query().etc is definitely less effort since you dont have to find your session. the elixir crew's +1 on having just query() is compelling since theyre the leading consumers of assignmapper. To get this straight, this was my personal opinion, not the one from the whole elixir crew. The other option which was discussed was to get rid of assignmapper altogether (in favor of defining the methods on our base class so that people can override those in their own classes ). No final decision was taken on this issue yet. -- 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: assign_mapper query methods
On Jun 1, 2007, at 12:46 PM, Gaetan de Menten wrote: To get this straight, this was my personal opinion, not the one from the whole elixir crew. The other option which was discussed was to get rid of assignmapper altogether (in favor of defining the methods on our base class so that people can override those in their own classes ). No final decision was taken on this issue yet. -- I like that latter idea too. assignmapper was a hack from day one. good job elixir crew ! ;) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: assign_mapper query methods
Both session.query(User).select() and User.query().select() seem more verbose than they need to be for my taste. However, I think most people (myself included) define a base class for all their mapped classes. I've always used this base class to provide the interface I want, no matter what interface sqlalchemy provides (and SA's API has changed quite a bit since 0.1). I suppose if anyone is going to pollute the namespace of the User class, it should be me, not sqlalchemy. That said, if I was new to sqlalchemy, I think I'd be scared to see session.query(User).select() as the recommended way in the tutorial. So, +1/2 from me on ditching assign_mapper (while keeping SessionContext, of course). shoe On 6/1/07, Michael Bayer [EMAIL PROTECTED] wrote: On Jun 1, 2007, at 12:46 PM, Gaetan de Menten wrote: To get this straight, this was my personal opinion, not the one from the whole elixir crew. The other option which was discussed was to get rid of assignmapper altogether (in favor of defining the methods on our base class so that people can override those in their own classes ). No final decision was taken on this issue yet. -- I like that latter idea too. assignmapper was a hack from day one. good job elixir crew ! ;) -- --- I'd give my right arm to be ambidextrous. --- --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: assign_mapper query methods
On Fri, Jun 01, 2007 at 10:50:33AM -0700, David Shoemaker wrote: Both session.query(User).select() and User.query().select() seem more verbose than they need to be for my taste. However, I think most people (myself included) define a base class for all their mapped classes. Uhm, that (few) people I know just use assign_mapper as demonstrated in the many tutorials. Even myself. And now that you mention it I like the idea. Not duplicating what SA is providing but rather making your own life easier. I've always used this base class to provide the interface I want, no matter what interface sqlalchemy provides Now I'm curious. Could you share your base class? That said, if I was new to sqlalchemy, I think I'd be scared to see session.query(User).select() as the recommended way in the tutorial. From lurking on IRC I'm sure most people are indeed scared by SA. :) Christoph --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: assign_mapper query methods
I used to have: .set(**kw) .update(whereclause, **kw) # this does table.update().execute() .count(whereclause) # table.count(whereclause).scalar() .delete_one(id) .load(*args) # returns a mapper with a bunch of eager loads .add_properties(dict) Luckily, great minds think alike and I was able to ditch count and add_properties when I upgraded from 0.1.7 to the 0.3 series. The .load() method is very handy and I think other people might find it useful: @classmethod def load(cls, *args): loads = [eagerload(prop) for prop in args] return cls.options(*loads) It fits my usage patterns well, at least (which is to define everything as lazy-load relations and use .load() to eager load them when it makes sense). shoe On 6/1/07, Christoph Haas [EMAIL PROTECTED] wrote: On Fri, Jun 01, 2007 at 10:50:33AM -0700, David Shoemaker wrote: Both session.query(User).select() and User.query().select() seem more verbose than they need to be for my taste. However, I think most people (myself included) define a base class for all their mapped classes. Uhm, that (few) people I know just use assign_mapper as demonstrated in the many tutorials. Even myself. And now that you mention it I like the idea. Not duplicating what SA is providing but rather making your own life easier. I've always used this base class to provide the interface I want, no matter what interface sqlalchemy provides Now I'm curious. Could you share your base class? That said, if I was new to sqlalchemy, I think I'd be scared to see session.query(User).select() as the recommended way in the tutorial. From lurking on IRC I'm sure most people are indeed scared by SA. :) Christoph -- --- I'd give my right arm to be ambidextrous. --- --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: assign_mapper query methods
assign_mapper is doing five different things: 1 Hide the session context and session 2 .query() 3 shadowed query methods (get*/select*/count/join*/etc) 4 shadowed session methods (flush/delete/save/etc) 5 connecting a DynamicMetaData whenever it needs to (1) we all agree is very useful. (2) is more straightforward to the user than session.query(MyClass). (3) is under probation. (4) I haven't used so I'm not sure if it's better or worse than session.* . But grafting fewer rather than more methods onto the mapped class makes sense. (5) is maybe being done by the session_context rather than assign_mapper, so perhaps it doesn't apply here. I just saw a Pylons recipe that said you can use a DynamicMetaData in your model *if* you use assign_mapper; I'm not sure why. http://docs.pythonweb.org/display/pylonscookbook/SQLAlchemy+for+people+in+a+hurry Given that all this is in control of the session_context, why not make assign_mapper a method of it, with boolean flags to enable method decoration: session_context.map(MyClass, table, query_methods=True, session_methods=True) or: session_context.query_methods = True session_context.session_methods = True session_context.map(MyClass, table) If we hang the query methods off .query(), can we hang the session methods off .session()? Or .store. (But not .objectstore, ugh.) Michael Bayer wrote: as it turns out, assign_mapper's monkeypatched methods (and they are all monkeypatched, not sure why you singled out query()) .query() is a class method that's actually a lambda. Very strange. The other methods looked like they were assigned more straightforwardly but maybe that's just a superficial appearance. They don't use lambdas though. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: assign_mapper query methods
On Jun 1, 2007, at 6:47 PM, Mike Orr wrote: (4) I haven't used so I'm not sure if it's better or worse than session.* . But grafting fewer rather than more methods onto the mapped class makes sense. instance.flush() is often misused, since flush() with just one instance wont always flush dependent instances. session.flush() is preferred, so ive considered whacking this since i think instance.flush() is not as common a use case as people might think (and they can say session.flush([instance]) if they really want the single-instance flush). 5 connecting a DynamicMetaData whenever it needs to (5) is maybe being done by the session_context rather than assign_mapper, so perhaps it doesn't apply here. I just saw a Pylons recipe that said you can use a DynamicMetaData in your model *if* you use assign_mapper; I'm not sure why. http://docs.pythonweb.org/display/pylonscookbook/SQLAlchemy+for +people+in+a+hurry we assignmapper has nothing to do with metadata or engines at all. also i kind of want to log in and edit that. DynamicMetaData, it was recently agreed, is not of general use. it connects to a particular engine within the current thread only. Pylons generally does not require any engine to be bound to the metadata at all since it binds the engine to the session. Given that all this is in control of the session_context, why not make assign_mapper a method of it, with boolean flags to enable method decoration: session_context.map(MyClass, table, query_methods=True, session_methods=True) or: session_context.query_methods = True session_context.session_methods = True session_context.map(MyClass, table) i think assignmapper is a much more second class citizen than session_context. people are at last talking about making their own common base class with actual methods on them, instead of using any of this monkeypatch stuff. If we hang the query methods off .query(), can we hang the session methods off .session()? Or .store. (But not .objectstore, ugh.) .session maybe. .query() is a class method that's actually a lambda. Very strange. The other methods looked like they were assigned more straightforwardly but maybe that's just a superficial appearance. They don't use lambdas though. i use lambdas for short anonymous functions all the time ? oh well i guess im under arrest by the style police again. (repeat offender...) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: assign_mapper query methods
heres the question. Query gets 10 new methods one day. do we then add 10 methods to assign_mapper() ? must the user class be a total clone of Query ? assign_mapper just bugs me for this reason. hence i like entity.query() better. im not sure which one youre saying you prefer ? On May 31, 5:46 pm, Mike Orr [EMAIL PROTECTED] wrote: What are future plans for the assign_mapper query methods? MyClass.select(...) -- works great. A clear advantage for assign_mapper over the regular mapper. MyClass.filter(...) -- doesn't exist. MyClass.query().filter(...) -- works but is undocumented and requires a convoluted monkeypatch in the source. Not so clear an advantage over the regular mapper because it's so verbose. The third is the one I've found most useful. That way I can have functions that return a Query, and the caller can call .select(), .select(offset=,limit=), or .count() as they wish. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: assign_mapper query methods
TOFU day? Okay, me too. ;) If I may cast a vote: yes, please add these 10 methods (if they are remotely connected to selecting or changing rows) and start with .filter(). I'm working with assign_mapped objects most the time and just have to use a completely different (Query) syntax if I want to .filter(). It's great that the .filter() exists and that Query has adopted the functionality of SelectResults. But even if it would be extra work I'd love to see the methods be available both for the bare Query object as well as for a mapped class. That keeped my code more consistent. Otherwise I'll probably stop using assign_mapper - what would a pity - for not having to explain to my coworkers why using two different way to play with the database. Christoph On Thu, May 31, 2007 at 08:47:01PM -0700, Michael Bayer wrote: heres the question. Query gets 10 new methods one day. do we then add 10 methods to assign_mapper() ? must the user class be a total clone of Query ? assign_mapper just bugs me for this reason. hence i like entity.query() better. im not sure which one youre saying you prefer ? On May 31, 5:46 pm, Mike Orr [EMAIL PROTECTED] wrote: What are future plans for the assign_mapper query methods? MyClass.select(...) -- works great. A clear advantage for assign_mapper over the regular mapper. MyClass.filter(...) -- doesn't exist. MyClass.query().filter(...) -- works but is undocumented and requires a convoluted monkeypatch in the source. Not so clear an advantage over the regular mapper because it's so verbose. The third is the one I've found most useful. That way I can have functions that return a Query, and the caller can call .select(), .select(offset=,limit=), or .count() as they wish. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: assign_mapper query methods
maybe keep only _one_ method which gives a fullblown Query() object, which then can be used as one wish? On Friday 01 June 2007 06:47:01 Michael Bayer wrote: heres the question. Query gets 10 new methods one day. do we then add 10 methods to assign_mapper() ? must the user class be a total clone of Query ? assign_mapper just bugs me for this reason. hence i like entity.query() better. im not sure which one youre saying you prefer ? On May 31, 5:46 pm, Mike Orr [EMAIL PROTECTED] wrote: What are future plans for the assign_mapper query methods? MyClass.select(...) -- works great. A clear advantage for assign_mapper over the regular mapper. MyClass.filter(...) -- doesn't exist. MyClass.query().filter(...) -- works but is undocumented and requires a convoluted monkeypatch in the source. Not so clear an advantage over the regular mapper because it's so verbose. The third is the one I've found most useful. That way I can have functions that return a Query, and the caller can call .select(), .select(offset=,limit=), or .count() as they wish. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
