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 at http://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
-~----------~----~----~----~------~----~------~--~---
