ok, a lot going on down there...if you want to make a mapper on an
class and have it be *the* mapper for that class, do this:
m = mapper(cls, table, is_primary=True)
Which "clear_mapper()" should also do, but i think its more direct
for the new mapper to assert itself as the primary
On Jan 23, 2006, at 4:08 PM, [EMAIL PROTECTED] wrote:
one thing that is a concern
for me, however, is that the
dependency graph seems to
keep on growing even though
only a single C1/C2 pair is
being updated. (i've included
that task dump output below).
made a small fix in 840 that properly cl
hi,
i'm trying to do something which is
perhaps fundamentally ill-advised,
but it would be great if something
like this could work.
the code is below, but it probably
could use some explanation.
i start with 2 tables 't1' and 't2a',
where 't2a' FKs into 't1'. naturally,
i create a relation betw
On Jan 23, 2006, at 5:41 PM, Michael Bayer wrote:
hmm does it really ? I am most accustomed to Oracle where getting
just the first row back of a huge result set is not much different
than just getting one (and also, Oracle doesnt even have 'limit', and
I have instead hacked together some "rowi
On Jan 23, 2006, at 2:50 PM, [EMAIL PROTECTED] wrote:
also curious why you have a separate step for
generating primary keys, since that behavior is built-in via
sequences or
"defaults".
hmm; i was having some issues with that
before, but you're right, it seems to
work without. i'm not sure wh
hmm does it really ? I am most accustomed to Oracle where getting
just the first row back of a huge result set is not much different
than just getting one (and also, Oracle doesnt even have 'limit', and
I have instead hacked together some "rowid" type of thing that doesnt
work very well, s
the following minor patch makes
selectone() much faster for large
result sets:
---
Index: mapping/mapper.py
===
--- mapping/mapper.py (revision 839)
+++ mapping/mapper.py (working copy)
@@ -416,6 +416,7 @@
def selectone(self
On Jan 23, 2006, at 1:55 PM, Michael Bayer wrote:
So they are adding some
overhead to the commit, but not a lot. They are definitely not being
manifest as any additional SQL or anything like that.
hi mike,
thanks as always for the response.
i do understand (and see) that the actual sql
sent t
[EMAIL PROTECTED] wrote:
>
> one thing that is a concern
> for me, however, is that the
> dependency graph seems to
> keep on growing even though
> only a single C1/C2 pair is
> being updated. (i've included
> that task dump output below).
>
OK, what you are seeing there, specifically with the lin
On Jan 20, 2006, at 9:51 PM, Michael Bayer wrote:
update and try it again. the fix i made for you yesterday was
slightly incorrect. youll notice that the dependency graph produced
for the second commit is much smaller after you update this change.
hi mike,
thanks for the update -
things se
10 matches
Mail list logo