Also, we've noticed (well, postgres did it), that the most internal
select (for that same B-level) of the polymorphic_union has 2
xxx.id AS id columns:
FYI, the problem is made by polymorphic_union() which does a
per-column renaming select over the A.join(B), and because the join
has both
Hi all,
I'm still learning SA, so please forgive me, if I'm asking something obvious or
have overlooked something in the docs...
The subject onyl gives a vague idea of what I'm trying to accomplish, but since
I couldn't find better term for it, I had trouble searching the lists, docs,
etc.
Tower Hill Insurance Group http://www.thig.com (Gainesville, FL, USA)
=
JOB DESCRIPTION
-
We're looking for a talented, enthusiastic programmer to join our web
team. You'll be responsible for supporting/enhancing
Karl Guertin schrieb:
Looks like you want recursive single table inheritance [1].
It doesn't need to be recursive, just a two-level parent-child relation. And I
don't want to add any columns, so I was thinking that table inheritance is not
the right approach, but I'm not sure about that.
Chris
On 1/25/07, Christopher Arndt [EMAIL PROTECTED] wrote:
It doesn't need to be recursive, just a two-level parent-child relation. And I
don't want to add any columns, so I was thinking that table inheritance is not
the right approach, but I'm not sure about that.
I was thinking that you could
You could do this in a single join using COALESCE on the fallback columns.
Rick
On 1/25/07, Karl Guertin [EMAIL PROTECTED] wrote:
On 1/25/07, Christopher Arndt [EMAIL PROTECTED] wrote:
It doesn't need to be recursive, just a two-level parent-child relation.
And I
don't want to add any
COALESCEwow i need to read some SQL books again... :)
On Jan 25, 2007, at 11:17 AM, Rick Morrison wrote:
You could do this in a single join using COALESCE on the fallback
columns.
Rick
On 1/25/07, Karl Guertin [EMAIL PROTECTED] wrote:
On 1/25/07, Christopher Arndt [EMAIL
Dude, you should be WRITING them!
On 1/25/07, Michael Bayer [EMAIL PROTECTED] wrote:
COALESCEwow i need to read some SQL books again... :)
On Jan 25, 2007, at 11:17 AM, Rick Morrison wrote:
You could do this in a single join using COALESCE on the fallback
columns.
Rick
On
Ya, the post_populate hook w/b great -- getting the callback to work
was kinda tricky, and I'm worried calling back to internals like that.
Calling signatures often change on internals.
On 1/25/07, Michael Bayer [EMAIL PROTECTED] wrote:
yup that would be how you can do that right now.
i
On Jan 25, 2007, at 9:35 AM, Christopher Arndt wrote:
As you can see 'parent_id' is a self-referencing FK to the
bookmarks table. The
idea now is to allow users to have their own copies of mapped
'Bookmark'
objects, that are a sort of child of an existing 'Bookmark' object
and allow
ok show me how youre doing it and ill see if i should make something
more solid for that.
On Jan 25, 2007, at 11:52 AM, Rick Morrison wrote:
Ya, the post_populate hook w/b great -- getting the callback to work
was kinda tricky, and I'm worried calling back to internals like that.
Calling
we just implemented our very first oracle BLOB support in 0.3.4.
havent tested CLOBs yet...this may require an explciit type in the
oracle module along the same lines as OracleBinary (i.e. OracleText,
or OracleCLOB perhaps). one thing I can say though, cx_oracle's
support for LOBs is
K, here's a snipppet that shows the populate_instance catch. It's
pretty straightforward, but the way that the hook takes (row,
instance) in that order, while the callback to the mapper takes
(instance, row) got me thinking about calling back to internals and
API stability.
def
Minor question: wouldn't it be more consistent to either apply echo to
all pool logging, or get rid of it and let logger settings control it?
Here's a patch for the former.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Reasonable people can differ here, but I agree that if what you care
about is a side effect, rather than a resulting list, using a for loop
is more clear than a list comprehension. (I suspect it is also more
performant since you are not allocating and populating a list object
for no reason.)
just habit ...i dont like one liners with :, also makes it easy to
tack on conditionals...feel free to submit a patch for all those if
theyre really bothering you (i guarantee program speed /mem usage will
not budge in any measurable way).
On Jan 25, 4:30 pm, [EMAIL PROTECTED] wrote:
there are
I'm restarting it after the first fetchall() finishes.
My experience with postgresql/psycopg2 is that you can tell the
connection is dead when you next try to call cursor(), but that isn't
happening here because of the queue problem I described.
Here's the output with pool logging on, if that
i have added a switch for lazy on/off to that 115-case full
combination test for A-B inheritance and relations.
For lazy=True all is ok.
For lazy=False, i am setting lazy=False only for those relations which
refer to klas not a subklas to the main one.
The result is 8 cases fail, all of same
self-referential eager loads are never going to be supported. the bug
here is that the eager loader isnt checking hard enough to see that its
in fact self-referential.
On Jan 25, 6:12 pm, [EMAIL PROTECTED] wrote:
i have added a switch for lazy on/off to that 115-case full
combination test for
I am evaluating SQLAlchemy for a new project we are starting up and it
looks great. The only remaining question I have about it is if there
are some recommended best practices for using it as a agile-data style
persistence layer for application development. (something like:
20 matches
Mail list logo
