[sqlalchemy] Re: generative queries
On Sep 16, 2008, at 3:51 AM, Grimsqueaker wrote:
I'm having some trouble using generative queries. In my case, I want
to compile a query and then add further from (join) clauses onto it
and change the column clause so that I get different results each
time. I can add from, where and column clauses easily using the
provided methods, but there seems to be no provision for removing
clauses. Is this intentional or is it an oversight?
Can anyone provide some insight into this issue?
The level of state which Query builds up for some generations is
fairly complex so we've balked on adding reversibility throughout
for now.
You can specify any custom set of columns and get a result immediately
using values() however:
query.values(MyClass.id, MyClass.name,
func.max(MyClass.foo).label('foo'))
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Declarative documentation
Hi all, I'm a new user (like this week) of SqlAlchemy and I'm trying to find more information about using the Declarative system. In particular I'm trying to build a hierarchical table with one-to-many relationships within the table. So if anyone knows where there might be some additional documentation about this, examples or just some guidance, I'd very much appreciate it!! Thanks in advance, Doug --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Problem with coverage and sqlalchemy declarative synonym?
Over on the TurboGears list a TG2 user pointed out a problem that arises when nosetests --with-coverage is run on a project with a sqlalchemy identity model: http://groups.google.com/group/turbogears/t/7fd3639a5a4d4b8c I dug into it and have reproduced the problem outside of TurboGears 2 and without nose: http://paste.turbogears.org/paste/7051 I've also shown that the problem isn't there for a plain Python property (in contrast to a sqlalchemy synonym): http://paste.turbogears.org/paste/7052 So, it looks like a problem maybe with the metaclass that sqlalchemy uses to build properties, or with coverage not understanding what that metaclass produces, or something. Or is there something else I'm missing? Doug --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Problem with coverage and sqlalchemy declarative synonym?
Doug Latornell wrote:
Over on the TurboGears list a TG2 user pointed out a problem that
arises when nosetests --with-coverage is run on a project with a
sqlalchemy identity model:
http://groups.google.com/group/turbogears/t/7fd3639a5a4d4b8c
I dug into it and have reproduced the problem outside of TurboGears 2
and without nose: http://paste.turbogears.org/paste/7051
I've also shown that the problem isn't there for a plain Python
property (in contrast to a sqlalchemy
synonym): http://paste.turbogears.org/paste/7052
So, it looks like a problem maybe with the metaclass that sqlalchemy
uses to build properties, or with coverage not understanding what that
metaclass produces, or something. Or is there something else I'm
missing?
Doug
Seems to be a problem in coverage. This narrows down a problem that was
first seen only when running inside Bitten.
$ cat c.py
def foo(somearg):
class Bar(object):
def __getattr__(self, attribute):
return getattr(somearg, attribute)
assert 'somearg' not in Bar.__dict__
foo('hi')
$ python c.py
$ coverage -e
$ coverage -x c.py
Traceback (most recent call last):
File /Users/jek/bin/coverage, line 8, in module
load_entry_point('coverage==2.80', 'console_scripts', 'coverage')()
File build/bdist.macosx-10.5-i386/egg/coverage.py, line 978, in main
File build/bdist.macosx-10.5-i386/egg/coverage.py, line 398, in
command_line
File c.py, line 8, in module
foo('hi')
File c.py, line 6, in foo
assert 'somearg' not in Bar.__dict__
AssertionError
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Problem with coverage and sqlalchemy declarative synonym?
On Sep 16, 2008, at 7:25 PM, Doug Latornell wrote:
Over on the TurboGears list a TG2 user pointed out a problem that
arises when nosetests --with-coverage is run on a project with a
sqlalchemy identity model:
http://groups.google.com/group/turbogears/t/7fd3639a5a4d4b8c
I dug into it and have reproduced the problem outside of TurboGears 2
and without nose: http://paste.turbogears.org/paste/7051
I've also shown that the problem isn't there for a plain Python
property (in contrast to a sqlalchemy
synonym): http://paste.turbogears.org/paste/7052
So, it looks like a problem maybe with the metaclass that sqlalchemy
uses to build properties, or with coverage not understanding what that
metaclass produces, or something. Or is there something else I'm
missing?
I've seen this identical issue with Bitten, and its not a SQLAlchemy
one.
Here's the ticket: http://www.sqlalchemy.org/trac/ticket/1138
Replace your test case with this script:
def foo(somearg):
class Bar(object):
def __getattr__(self, attribute):
return getattr(somearg, attribute)
assert 'somearg' not in Bar.__dict__
foo('hi')
I just ran it with the coverage.py that we have in SQLAlchemy and
the bug reproduces.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Problem with coverage and sqlalchemy declarative synonym?
Thanks for the quick replies, Jason and Michael, and for the very
succinct test case. I will try to raise this with Ned Bachelor over
at http://nedbatchelder.com/code/modules/coverage.html
Doug
On Sep 16, 4:55 pm, Michael Bayer [EMAIL PROTECTED] wrote:
On Sep 16, 2008, at 7:25 PM, Doug Latornell wrote:
Over on the TurboGears list a TG2 user pointed out a problem that
arises when nosetests --with-coverage is run on a project with a
sqlalchemy identity
model:http://groups.google.com/group/turbogears/t/7fd3639a5a4d4b8c
I dug into it and have reproduced the problem outside of TurboGears 2
and without nose:http://paste.turbogears.org/paste/7051
I've also shown that the problem isn't there for a plain Python
property (in contrast to a sqlalchemy
synonym):http://paste.turbogears.org/paste/7052
So, it looks like a problem maybe with the metaclass that sqlalchemy
uses to build properties, or with coverage not understanding what that
metaclass produces, or something. Or is there something else I'm
missing?
I've seen this identical issue with Bitten, and its not a SQLAlchemy
one.
Here's the ticket: http://www.sqlalchemy.org/trac/ticket/1138
Replace your test case with this script:
def foo(somearg):
class Bar(object):
def __getattr__(self, attribute):
return getattr(somearg, attribute)
assert 'somearg' not in Bar.__dict__
foo('hi')
I just ran it with the coverage.py that we have in SQLAlchemy and
the bug reproduces.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
