Thank you Mariano.
I tested your solution, but it didn't work as well as your previous one
- since I use a lot of self referential, polymorphic entities; they may
not like union_all :-(
But it does provides a simplier approach if you're not using it the way
I do :)
Thanks again!
Best
On 04/25/2013 11:17 AM, Richard Gerd Kuesters wrote:
Well. I'm pretty interested :) I did find your solution very flexible, thou.
Thanks a lot,
Richard.
For completeness, here is a pure sqlalchemy version of the same
recursive ideas:
def _hierarchy():
# TODO: check if
Hmmm, it looks interesting also! I'm just using the postgres version of
your previous solution, and modified / added some features, so pg type
ARRAY could be used with labels and to specify a maximum recursion level
(let's say, do not go more then 10 levels (not relative to start_node,
Hey Mike!
I'm almost there :) The only problem now is with a column that returns a
postgres *ARRAY* type.
When labeling is not applied, I get the same error as before:
*sqlalchemy.exc.NoSuchColumnError: Could not locate column in row for
column 'connect_path'*
But, when I apply a label on
Ha! A little google search and ...
https://groups.google.com/forum/?fromgroups=#!topic/sqlalchemy/FHuCN-X9L8A
https://groups.google.com/forum/?fromgroups=#%21topic/sqlalchemy/FHuCN-X9L8A
Voilà!
:-)
Kind regards,
Richard.
On 04/26/2013 03:50 PM, Richard Gerd Kuesters wrote:
Hey Mike!
I'm
is that 0.8? that particular issue should have been fixed.
On Apr 26, 2013, at 2:50 PM, Richard Gerd Kuesters rich...@humantech.com.br
wrote:
Hey Mike!
I'm almost there :) The only problem now is with a column that returns a
postgres ARRAY type.
When labeling is not applied, I get
Hi all,
I've been playing with sqla_hierarchy from
https://github.com/marplatense/sqla_hierarchy .
The problem is: the returned query appends 3 columns: level (Integer),
is_leaf (Boolean) and connect_path (pg ARRAY).
So far, so good. If I execute the query using
Well, probably nevermind because I made a workaround that satisfies me
(may not be elegant, but that's OK).
Basically, I created the o type a little different: o =
type('MyObjExt', (Base,), {'__table__':q.alias('q')}) and append it to
the query like: session.query(MyObj,
Minor tweaks, may it be useful for someone:
*q1 = hierarchy_query.alias('q1')**
**s = select(**
**[q1.c.id, q1.c.level, q1.c.is_leaf, q1.c.connect_path],**
**from_obj=q1**
**).alias('o')**
**MyObjExt = type('MyObjExt', (Base,), {'__table__': s})**
**
# objects :)
rs =
why not just say session.query(MyObj, q.alias()) ?creating ad-hoc
mappers is relatively expensive.
On Apr 25, 2013, at 8:56 AM, Richard Gerd Kuesters rich...@humantech.com.br
wrote:
Well, probably nevermind because I made a workaround that satisfies me (may
not be elegant, but
Hmmm ... Might as well :) I didn't know I could use an alias in
session.query. Thanks Mike!
Cheers,
Richard.
On 04/25/2013 11:03 AM, Michael Bayer wrote:
why not just say session.query(MyObj, q.alias()) ?creating
ad-hoc mappers is relatively expensive.
On Apr 25, 2013, at 8:56
On 04/25/2013 10:22 AM, Richard Gerd Kuesters wrote:
Hi all,
I've been playing with sqla_hierarchy from
https://github.com/marplatense/sqla_hierarchy .
That code of that sqla_hierarchy was written to provide a limited
support for cte, from the time when sqalchemy didn't have cte.
Since
Well. I'm pretty interested :) I did find your solution very flexible, thou.
Thanks a lot,
Richard.
On 04/25/2013 11:08 AM, Mariano Mara wrote:
On 04/25/2013 10:22 AM, Richard Gerd Kuesters wrote:
Hi all,
I've been playing with sqla_hierarchy from
Well, not the desired result ... Now things justs blows :-)
*sqlalchemy.exc.NoSuchColumnError: Could not locate column in row for
column 'anon_1.level'*
Cheers,
Richard.
On 04/25/2013 11:03 AM, Michael Bayer wrote:
why not just say session.query(MyObj, q.alias()) ?creating
ad-hoc
Yup, I agree with you, but things are a little out of hand for me to use
ORM-level queries. I'll see what I can do ...
Thanks! :)
Cheers,
Richard.
On 04/25/2013 11:31 AM, Michael Bayer wrote:
you'd need to organize things differently for the column grabbing to
work out.
I'd advise producing
if the original q is a select(), this should work:
query(MyClass, q.c.somecol, q.c.someothercol).from_statement(q)
if not then I guess I'll screw around with it to see what works.
On Apr 25, 2013, at 10:37 AM, Richard Gerd Kuesters rich...@humantech.com.br
wrote:
Yup, I agree with you, but
Yeah, well, it is a select but didn't work. I also made another select
on top of it (to be sure), but the error persists (could not locate
column ...).
Nevermind about it, I think it's not a question of good usage of SA I
think :)
Thanks for your help!
Cheers,
Richard.
On 04/25/2013
using explicit labels is the best approach to bypass SQLA's labeling schemes,
such as this example:
from sqlalchemy import *
from sqlalchemy.orm import *
from sqlalchemy.ext.declarative import declarative_base
Base = declarative_base()
class A(Base):
__tablename__ = 'a'
id =
Hmm, I was thinking in labeling this evening. I'll try tomorrow when
I get to work and then try this alternative. Maybe it works and avoids
my workaround :)
Thanks Mike.
Best regards,
Richard.
Em
2013-04-25 19:20, Michael Bayer escreveu:
using explicit labels is
the best approach to
19 matches
Mail list logo
