[sqlalchemy] Re: Dynamic or-Statement
build the OR clause separately: list = [] list.append(users.c.user_id==id) list.append(users.c.user_name==name) statement = user.select(or_(*list)) or statement.append_whereclause(or_(*list)) alternate method: critrerion = users.c.user_id==id criterion = criterion.or(users.c.user_name==name) crtierion = criterion.or(crit) ... statement = user.select(criterion) On Nov 8, 2006, at 3:33 AM, Dominik Neumann wrote: Hello list, i need to build a dynamic where-statement, linked by the OR-operator. In the docs there are only examples with AND. example (snippet from docs): statement = user.select() statement.append_whereclause(user.c.user_id == id) statement.append_whereclause(user.c.user_name == name) is it possible to get here the OR instead of the AND-operator? Best Regards, -dn --~--~-~--~~~---~--~~ 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: polymorphic_identity determination
On Nov 8, 2006, at 12:04 AM, Randall Smith wrote: That leads to the part I'm stuck on; mapper inheritance. When finished, session.query(Employee).select() should list all employee as instances of their specific classes and session.query(Engineer).select() should list all engineers ... So how do I set up the mappers to accomplish this? The polymorphic_on/polymorphic_identity method seems to only accommodate 1 level of inheritance. The Engineer mapper will inherit from the Employee mapper, but will have no polymorphic_identity. beacuse the polymorphic union is manually constructed, if you want multi-level loading you have to construct individual polymorphic unions for each class from which you want to load polymorphically, and specify it as the select_table argument for each mapper that requires polymorphic loading. when you say query(Employee).select(), it uses the mapper assigned to Employee and the select_table which you specified. when you say query(Engineer).select(), the Employee mapper is not used; it uses the Engineer mapper and the select_table specified on *that* mapper. it *is* in the cards that the polymorphic_union query will probably become more automated in a future release. the polymorphic_union function itself is the first version of this automation and im sort of road testing just that level of automation to start with. for your other questions: 1. a mapper inheriting from another mapper is mostly significant with regards to the persistence of object instances, i.e. during flush(), since there is an entire set of dependencies between inheriting classes. with regards to selecting and populating, an inherited mapper inherits the properties of the parent mapper, i.e. the column- mapped attributes as well as the relation()'s which you have attached to the parent mapper. when you add the polymorphic_identity into the mix, an additional set of logic occurs during the _instance() method on mapper, which is the method that receives a row and produces an object instance. it just looks at the polymorphic_on column in each incoming row and delegates the instance construction to the appropriate mapper. so the loading of polymorphic entities can be totally understood by just looking at the queries issued, and then looking at the rows that come back. each row needs some kind of identifying type in order to determine the class to be instantiated. 2. the concrete flag refers to an inheriting mapper that stores its entire set of data in its own table, and does not need any columns from the parent mapper's table in order to map an instance. so to load a particular class of entity involves querying only one table, and no join is required. this flag is only meaningful in inheritance relationships. I just noticed that one of my docstrings in the constructor of the Mapper class is incorrect regarding local_table and concrete as well, in case that was confusing you. it should refer to single table inheritance. 3. select_table should be used when you want polymorphic loading from a particular mapper, and the inheritance relationship spans over more tables than just what is defined in that mapper. this means you use it for joined table and concrete inheritance, but not single table. if a set of mappers mixes the approaches, then youd probably want to use select_table. --~--~-~--~~~---~--~~ 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] Clases with __slots__ attribute
Hi, I've detected that when a class has __slots__ attribute, a mapper cannot be build because the sqlalchemy tries to create a magic attribute and fails: File build/bdist.linux-x86_64/egg/sqlalchemy/orm/attributes.py, line 672, in init_attr AttributeError: 'MyClass' object has no attribute '_MyClass__sa_attr_state' Can anybody help me? --~--~-~--~~~---~--~~ 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: Column __repr__ with sqlalchemy types instead of db-specific object instances?
Michael Bayer wrote: __repr__() really annoys me because no matter what i do with it, people tell me im using it incorrectly. technically, __repr__() is supposed to return a string that when eval'ed would return the object instance. which is not realistic for an object like Table since its an enormous construction. if you want to take Tables and produce some kind of string representation, I recommend you create yourself a SchemaVisitor...since __repr__() is not something id write code against in this case. Thanks. In my limited case the __repr__ is close enough to treat it as a string for post-processing. All I need is to replace the field type instance with the proper constructor. These are one-off operations in order to commit a matching sqlalchemy model for existing versioned DDL to the repository. Would it be useful to add __repr__() roundtripping as long-term trac ticket? Acknowledging that full general-case __repr__ may be impractical, if anyone saw the ticket and had ideas for incremental improvements, __repr__ would seem to be amenable to test cases, documented limitations, etc. --~--~-~--~~~---~--~~ 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: Constructing where-clauses dynamically
Michael Bayer wrote: ok let me rephrase that... i have concerns. i think the concerns could be addressed, and we might be able to add this kind of feature...but i dont want to rush into it singlehandedly. I won't blame you for that. I'll help out as much as possible given my busy schedule. heres the things that should be resolved: - we add non-column properties to SomeClass.c. people will get confused that SomeClass.c has a bunch of stuff on it that mytable.c does not. do we change the name of 'c' ? Part of me say adding extra columns to SomeClass.c wouldn't be so confusing, and would actually be intuitive. For example in the original question that started this thread it seemed logical to me that 'order' should have been in there since it was a mapper property. Sure maybe it's a bit more than meets the eye at first, but I think it's very logical to have mapper properties in SomeClass.c but not have them in table.c. As long as it's well documented I don't think it would be a problem. The only other thing I can think of is to create a function that would return a cols object. In the spirit of python's getattr() function: from sqlalchemy.orm import getcols c = getcols(SomeClass) session.query(SomeClass).select(c.order == order) I often find myself assigning SomeClass.c to a local variable when I'm building a query anyway. It prevents excess verbosity. - people will say things like, SomeClass.c.order order. how do we interpret that ? esp. for composite foreign keys. I assume you're implicitly asking about the choice to use AND or OR to combine multiple comparisons of a composite key. For example (assume Order and SomeClass are related by user_id and quote_id): # given this order = Order(user_id=4, quote_id=5) session.query(SomeClass).select(SomeClass.c.order order) -- Do we generate this? WHERE some_class.user_id 4 AND some_class.quote_id 5 -- or this? WHERE some_class.user_id 4 OR some_class.quote_id 5 I don't think the , =, , and = operators would be very useful on most relationship comparisons; especially those with composite keys. However, the == and != operators are obviously useful in many cases. It's like comparing user-defined Python objects without explicit __gt__ and __lt__ implementations. Python 2.x compares the id() of the objects, while Python 3000 will raise a TypeError (I think that's the right error). The reasoning behind this decision[0] is that unless there is an explicit ordering for a given pair of objects, it doesn't make sense to compare them using the inequality operators. At any rate, I would recommend not implementing those comparison operations for relationships by default (at least not for multi-column relationships). If someone really needed them maybe they could create their own custom relationship subclass? [0] http://mail.python.org/pipermail/python-dev/2005-November/057925.html - is it really as simple as just producing the primary/foreign key columns of both sides ? i fear that a whole class of patterns are going to become apparent after adding that feature, and then people are going to complain about SA being broken until an entire HQL-like layer is added to implement all those features. maybe theyre going to stick SomeClass.c.order into the order_by clause, theyre going to stick it in func() calls, CAST calls, etc. and expecting all this magical behavior. pretty much every other feature of SA proved to be a gargantuan undertaking compared to how easy i thought it would be when i first wrote it :)how would this feature be presented ? Could we implement it as simply as possible for now and see how it's used? As new use cases come up we can either extend the implementation or explain why they are not supported (i.e. too complicated, inconsistent with other parts of SA, etc.). - is this feature also going to figure out all the joins from class A to B, if my query is based on class A and the criterion object is all the way on B? the way select_by, join_to works ? that seems trickier and i can see people expecting that behaivor as well. This is something I thought about immediately when I first imagined the idea. Personally, I don't really like the automagical join behavior because it's not explicit and can lead to obscure bugs that are hard to track down (why is this join suddenly returning the wrong results? ...hours later we discover that a new relationship was added that caused SA to pick a different relationship path for the join). The problem is that a seemingly unrelated (no pun intended) change can cause these magic joins to be interpreted differently. I tried to use that behavior once myself but quickly discarded it when SA used some other relationship path than the one I intended to use. In general I think it's best to require explicit relationship paths at all times and give useful errors when the given path can't be determined using those strict rules. if we
[sqlalchemy] Re: Constructing where-clauses dynamically
On Nov 8, 2006, at 10:00 PM, Daniel Miller wrote: q = session.query(User) c = getcols(User) q.select( (c.addresses.street == 'some address') (c.orders.items.item_name == 'item #4') ) ohh, wow. heh. i had this discomfort with adding relationships to c, but then you just wrapped up the whole mess of join_to/ join_via into one consistent syntax there, didnt you. youll notice in the docs for join_to/join_via theyre marked with alpha API (meaning I have been antsy with them anyway)so this syntax is compelling. you have to pipe in more often Dan ! --~--~-~--~~~---~--~~ 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: Column __repr__ with sqlalchemy types instead of db-specific object instances?
when you reflect a table from the DB, and you get back PGString, that is the actual type instance. In some cases, table reflection could be mapped to a type instance that is specific to that DB (such as MySQL's enum). i dont think changing the __repr__ of all the db- specific types to return a fake constructor is such a great idea. you can use the database-specific constructors, such as PGString or whatever, when constructing a Table. its just usually not so convenient. On Nov 8, 2006, at 5:35 PM, jeffk wrote: Michael Bayer wrote: __repr__() really annoys me because no matter what i do with it, people tell me im using it incorrectly. technically, __repr__() is supposed to return a string that when eval'ed would return the object instance. which is not realistic for an object like Table since its an enormous construction. if you want to take Tables and produce some kind of string representation, I recommend you create yourself a SchemaVisitor...since __repr__() is not something id write code against in this case. Thanks. In my limited case the __repr__ is close enough to treat it as a string for post-processing. All I need is to replace the field type instance with the proper constructor. These are one-off operations in order to commit a matching sqlalchemy model for existing versioned DDL to the repository. Would it be useful to add __repr__() roundtripping as long-term trac ticket? Acknowledging that full general-case __repr__ may be impractical, if anyone saw the ticket and had ideas for incremental improvements, __repr__ would seem to be amenable to test cases, documented limitations, etc. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
