youre looking for the mappers to express the relational concepts as fully as Tables. but thats what Tables are for, why not just use them ? SA's philosophy is very much about "dont pretend theres no database".
On Mar 9, 5:16 am, Glauco <[EMAIL PROTECTED]> wrote: > Michael Bayer ha scritto: > > > > > hey list - > > > I continue to be troubled by the slightly fragmented nature of SA's > > Query object (and the cousin SelectResults). When I work with > > Hibernate, I can see that their querying interface is a little more > > consistent than ours. We have flags that are used for some things, > > generative methods for others. > > > so id like to look into defining the next generation of query. Id > > like it to have a "quasi-generative" approach, like Hibernates. this > > means you can say: > > > q = q.where(<something>).order_by(<somethingelse>) > > > but also, its the same as: > > > q.where(<something>) > > q.order_by(<somethingelse>) > > > so its really the same instance (this is not how SelectResults works > > at the moment). > > > the whole business of using SelectResults, using SelectResultsExt, all > > that crap just to get a different API, id like to get rid of (i mean, > > itll stay there but you wont need it). im sorry ive made you all type > > that much. > > > This would be a rewrite of `Query`, and we'd leave the old one around > > in its usual place. Im thinking we could put this newer `Query` on > > the session under the method name `select()`. > > > Anyway, I put a wiki page over athttp://www.sqlalchemy.org/trac/wiki/QueryV4 > > , with like 2 lines of code what it might look like. > > > I would like folks to comment on it, and add use cases, sample code, > > things youd like to see. note that Im looking mostly for the Python > > API, and maybe a little bit of the method of specifying criterion, but > > not really a whole new object-query layer (like building a new HQL, or > > using AST-parsing, etc. i still think thats something else entirely). > > > Please think of something to add, particularly if you are working with > > polymorphic mappings, or youve had a lot to say in past iterations > > (i.e. like dmiller, dennis, etc). I dont want to make a move on this > > until something definitely cool and widely useful has been worked > > out. if we just have a vague notion of something, theres no > > point...while we can prototype it, if its a side thing then not enough > > people are going to use it (and therefore valid complaints wont be > > heard) unless we parade this thing down the main aisle. this query > > would hopefully be the last one we write for the SA core (since we are > > running out of reasonable method names on session ;) ). > > SA is a great Work, power and useful. Only think , probably is too much > finalised to oneTabel <-> OneMapper prototyping > > For example, my purpose now is to revisiting a lot of mapper created > from different programmers over a huge DB so it's very important for > maintain mappers clear, univocity in these mappers. > > I found different but not equal possibility in some operation for example: > > - It's not too clear because not all the features of the Table object is > not manteined in the Mapper. > > I've 3 mapper Amapper -> Bmapper -> Cmapper > > - Why, if i prefer to use Mapper instead of the Tbl direct qry, i must > anyway always explicity the join to other mapper, for retrieve all > selected records, Amapper.select_by( BmapperColumnCondition ) retrieve > always " select * from A where <clause>" so if i'm searching something > from B i must redesign selection qry.. > > - Why ( aa = Amapper, is a mapper > bb = Bmapper, is a mapper; > aa.Bmapper, is a Unit of Work) this let me use > Amapper.c.field == x but i cannot Use Amapper.Bmapper.c.field = y > > take in mind my work of maintain this huge library so if i must upgrade > Cmapper i don't want to manipulate ALL mapper referring to it > > I hope my explanation is clear, :-) Sorry for my poor English > > Glauco > -- > +------------------------------------------------------------+ > Glauco Uri - Programmatore > glauco(at)allevatori.com > > Sfera Carta Software® [EMAIL PROTECTED] > Via Bazzanese,69 Casalecchio di Reno(BO) - Tel. 051591054 > +------------------------------------------------------------+ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
