they were flushed ! the primary key is always fetched when the ORM does an
INSERT.
On Oct 20, 2011, at 5:38 PM, Russell Warren wrote:
> 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, tho
>
> 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
"sq
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
>> ther
>
> 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 d
On Oct 20, 2011, at 3:54 PM, Jeremy Jones wrote:
> We are moving from mysql to postgres and would like to have the same
> sort behavior in postgres that mysql provides. Unfortunately as the
> code was written for our application, it didn't always get an explicit
> "order by" because the behavior
On Oct 20, 2011, at 11:29 AM, Alex K wrote:
> Thanks!
>
> Very simple solve :)
>
> I just added:
> def content_comments_level_add(mapper, context, row, target, **flags):
> if mapper.class_ is Comment and 'AS level' in context.query.__str__():
> level = tuple(row)[-3]
> targe
We are moving from mysql to postgres and would like to have the same
sort behavior in postgres that mysql provides. Unfortunately as the
code was written for our application, it didn't always get an explicit
"order by" because the behavior that was in mysql worked how it was
"supposed to." Is the
Thanks!
Very simple solve :)
I just added:
def content_comments_level_add(mapper, context, row, target, **flags):
if mapper.class_ is Comment and 'AS level' in context.query.__str__():
level = tuple(row)[-3]
target.level = level
event.listen(mapper, 'populate_instance', con
On Oct 20, 2011, at 10:45 AM, Alex K wrote:
> I solve this problem with new custom Query class:
it appears all you're doing is injecting an extra column into the result.
Still not clear why column_property() doesn't work here. There's also the
populate_instance event which would allow you
I solve this problem with new custom Query class:
class HieSession(Session):
def __init__(self, *args, **kwargs):
super(HieSession, self).__init__(*args, **kwargs)
self._query_cls = HieQuery
class HieQuery(Query):
def instances(self, cursor, __context=None):
"""G
On Oct 20, 2011, at 4:03 AM, Alex K wrote:
>
> result2 = db.session.query(non_primary_mapper).from_statement('SELECT test.id
> AS test_id, test.user_id AS test_user_id, test.reply_id AS test_reply_id,
> test.text AS test_text FROM test LEFT OUTER JOIN "user" ON "user".id =
> test.user_id LIMI
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 on
On Wed, Oct 19, 2011 at 7:57 PM, Michael Bayer wrote:
>
> > but I can't add options contains_eager like
> > result = result.options(contains_eager(Comment.user))
>
> Well no because you're digging way into RECURSIVE queries which SQLA
> doesn't yet support very nicely. Mapping to them is not a p
13 matches
Mail list logo
