they were flushed ! the primary key is always fetched when the ORM does
an INSERT.
I know it *does* happen, just not *how*.
It seems that some of my confusion was mostly based entirely on a
peculiarity of the sqlite dialect. When I switch to Postgres it is
perfectly clear that the ids
On Oct 21, 2011, at 11:05 AM, Russell Warren wrote:
they were flushed ! the primary key is always fetched when the ORM does an
INSERT.
I know it does happen, just not how.
It seems that some of my confusion was mostly based entirely on a peculiarity
of the sqlite dialect. When I
Ok thanks. I actually feel better knowing I'm up against underlying
limitations.
Sorry for being a few steps behind you... I didn't initially understand your
initial comments about why you can't use bulk INSERT calls in a
backend-neutral way but with hindsight they are perfectly clear.
its
On Oct 20, 2011, at 1:49 AM, Russ wrote:
I understand this somewhat and had done that, but am still confused by one
thing: in my pure ORM case (for joe), how did the identity map get a hold
of the auto-increment ids when there was no apparent emitted SQL? It seems
there wasn't one
I understand this somewhat and had done that, but am still confused by one
thing: in my pure ORM case (for joe), how did the identity map get a hold
of the auto-increment ids when there was no apparent emitted SQL? It seems
there wasn't one done, although I suppose it could have been done
On Oct 20, 2011, at 4:49 PM, Russell Warren wrote:
I understand this somewhat and had done that, but am still confused by one
thing: in my pure ORM case (for joe), how did the identity map get a hold
of the auto-increment ids when there was no apparent emitted SQL? It seems
there wasn't
The joe addresses are there quite simply because you assigned them on
line 44:
The addresses are obviously there, yes. The ids are also there, though.
With no apparent select. That's the mystery to me.
--
You received this message because you are subscribed to the Google Groups
On Oct 18, 2011, at 3:40 PM, Russ wrote:
I often mix up the SQL expression language with the use of an ORM session,
and it is great that SQLAlchemy more than supports this.
But... what are the recommended ways to keep the session in sync with what
you do with the SQL expression stuff?
Thanks very much for the response... lots to chew on here.
well pretty much being saavy about expiration is the primary approach. The
rows you affect via an execute(), if they've been loaded in the session
they'd need to be expired from memory.
I understand this somewhat and had done
I often mix up the SQL expression language with the use of an ORM session,
and it is great that SQLAlchemy more than supports this.
But... what are the recommended ways to keep the session in sync with what
you do with the SQL expression stuff?
For example, with the ORM you can't really do a
10 matches
Mail list logo
