On 6/3/07, Michael Bayer [EMAIL PROTECTED] wrote:
- filter_by() would gain a new positional argument, which is
optional, which is either a string or list of strings indicating
property names, indicating a join path. when this argument is
present, a self-contained join among those mapped
finally I did sub query as follow, and worked. (Where, vcc_schema is
my database schema0
subquery_stmt =
select([vcc_schema.RoleElementsTable.c.roleId],and_(vcc_schema.RoleElementsTable.c.elementId
== elementsId,vcc_schema.RoleElementsTable.c.elementLevelId ==
all seems ok.
and ORM will become looking less SQLish (as .select being the most
SQLish word IMO)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to
These sound like a good progression of the library.
Would there be a way to turn on warnings if one were to use a
deprecated interface? Or if the programmer wants to be even more
strict, raise an exception? This wouldn't be the default, but rather
an available option.
On Jun 3, 2007, at 10:33 PM, Michael Bayer wrote:
one() raises an exception when theres not exactly one result, scalar
() does not. currently we have selectfirst() and selectone(), people
seem to like the dichotomy. [0] specifically adds LIMIT 1 OFFSET 0
to the query and i dont think
The use of scalar() here seems out of place with both the common CS usage of
the word (e.g. scalar == single-valued), and the use of scalar() in the SQL
layer. Single row results in the ORM are rows, not a single datatype. It's
another potential point of confusion, like the ORM .select() is/was.
On Jun 4, 2007, at 9:56 AM, Rick Morrison wrote:
The use of scalar() here seems out of place with both the common CS
usage of the word (e.g. scalar == single-valued), and the use of
scalar() in the SQL layer. Single row results in the ORM are rows,
not a single datatype. It's another
Well, I don't really see the connection between .scalar() and .list(), other
than they are kind of antonyms, but FWIW I always thought that .list() was
an odd duck anyway, seeing as how the arguably more Pythonic list(query)
works fine.
On 6/4/07, Michael Bayer [EMAIL PROTECTED] wrote:
On
Hi,
Does someone know if there's a database interface for MySQL's MaxDB or if
someone is developing it?
If not - is it much effort to develop that?
Best Regards,
Hermann
--
[EMAIL PROTECTED]
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
Well, I don't really see the connection between .scalar() and .list(),
other than they are kind of antonyms, but FWIW I always thought that .list()
was an odd duck anyway, seeing as how the arguably more Pythonic list(query)
works fine.
(expanding on this a bit)
More generally, it's the
On Jun 4, 2007, at 10:47 AM, Rick Morrison wrote:
Well, I don't really see the connection between .scalar() and .list
(), other than they are kind of antonyms, but FWIW I always thought
that .list() was an odd duck anyway, seeing as how the arguably
more Pythonic list(query) works
On Jun 4, 2007, at 3:27 AM, Neil Blakey-Milner wrote:
The joined tables are aliased as the path from the base object. In
this case, the jobtitle join is:
INNER JOIN strids AS positionprofiles__jobtitle ON
positionprofiles.jobtitleid = positionprofiles__jobtitle.id
The
On Monday 04 June 2007 18:03:05 Rick Morrison wrote:
Well, I don't really see the connection between .scalar() and
.list(), other than they are kind of antonyms, but FWIW I always
thought that .list() was an odd duck anyway, seeing as how the
arguably more Pythonic list(query) works fine.
On 6/4/07, Michael Bayer [EMAIL PROTECTED] wrote:
anyway, the filter on product/store and product/type example you just
mention presents a third scenario, which I wouldnt consider to fall
under the filter_by([attributes]) functionality, it would fall under
the regular join() call which
On Jun 4, 2007, at 12:09 PM, Neil Blakey-Milner wrote:
What do you think of me putting up the full pathological-case code
from Django ORM and SQLAlchemy on the SQLAlchemy wiki, and maybe see
if there are improvements to be found for that as well (since it uses
ILIKE and not equality and a
First, let me admit that I'm not an expert at Python.
I'm trying to test the newer versions of SQLAlchemy before I install
it on my server. According to
http://docs.python.org/inst/search-path.html, the PYTHONPATH should
add paths to the beginning of sys.path. The docs at
according to some new bright python idea, .eggs override PYTHONPATH.
so eiter kill the .egg.
There was some thread about this before, search for PYTHONPATH in the
group...
On Monday 04 June 2007 19:36:32 Paul Kippes wrote:
First, let me admit that I'm not an expert at Python.
I'm trying to
I found the thread about PYTHONPATH--interesting.
It does seem that eggs are not only preventing the expected behavior,
but they are also preventing the documented behavior.
However, I don't think that using eggs is the best choice for a fast
progressing library like SQLAlchemy--especially with
Hi,
I m currently playing with using sqlalchemy to map a pre-existing
database to objects. I ve had a quick look through the docs and not
being able to find anything about this.
Does SQLAlchemy support introspection (if thats the right word,
probably not) into existing databases, if so how? If
On Jun 4, 1:58 pm, Paul Kippes [EMAIL PROTECTED] wrote:
I found the thread about PYTHONPATH--interesting.
It does seem that eggs are not only preventing the expected behavior,
but they are also preventing the documented behavior.
However, I don't think that using eggs is the best choice
On Jun 4, 2007, at 2:31 PM, nathan harmston wrote:
Hi,
I m currently playing with using sqlalchemy to map a pre-existing
database to objects. I ve had a quick look through the docs and not
being able to find anything about this.
Does SQLAlchemy support introspection (if thats the right
On 6/4/07, Rick Morrison [EMAIL PROTECTED] wrote:
The use of scalar() here seems out of place with both the common CS usage of
the word (e.g. scalar == single-valued), and the use of scalar() in the SQL
layer. Single row results in the ORM are rows, not
a single datatype. It's another
That's one of the reasons I prefer to treat Query() like an iterator and
roll my own first-order functions like first() etc. -- see my other
message regarding this.
On 6/4/07, Mike Orr [EMAIL PROTECTED] wrote:
On 6/4/07, Rick Morrison [EMAIL PROTECTED] wrote:
The use of scalar() here
On 6/4/07, Paul Kippes [EMAIL PROTECTED] wrote:
I found the thread about PYTHONPATH--interesting.
It does seem that eggs are not only preventing the expected behavior,
but they are also preventing the documented behavior.
However, I don't think that using eggs is the best choice for a fast
On Jun 4, 3:11 pm, Mike Orr [EMAIL PROTECTED] wrote:
.first() -- returns first row
.one() -- returns first row, raise exception if more than one result
What if there are zero rows? Return None or raise an exception? I
find the former useful enough, but I imagine some people prefer the
On Jun 4, 2007, at 3:35 PM, Mike Orr wrote:
On 6/4/07, Paul Kippes [EMAIL PROTECTED] wrote:
I found the thread about PYTHONPATH--interesting.
It does seem that eggs are not only preventing the expected behavior,
but they are also preventing the documented behavior.
However, I don't
What kind of overhead is associated with using the autoload flag?
What kind of overhead would be associated with this over a network? (with a
remote database). Is there a way to dump the structure of a database to a
file and import this as a kind of module?
Thanks
Nathan
On 6/4/07, nathan harmston [EMAIL PROTECTED] wrote:
What kind of overhead is associated with using the autoload flag?
What kind of overhead would be associated with this over a network? (with a
remote database). Is there a way to dump the structure of a database to a
file and import this as
Michael Bayer wrote:
On Jun 4, 2007, at 6:47 PM, nathan harmston wrote:
What kind of overhead is associated with using the autoload flag?
What kind of overhead would be associated with this over a network?
(with a remote database). Is there a way to dump the structure of
a database
wongobongo wrote:
You mean something like this?
K
---
# Running a SQL Statement using SQLAlchemy
from sqlalchemy import *
dsn = 'mysql://root:[EMAIL PROTECTED]:3306/tester'
# Create a database engine
db = create_engine(dsn)
# Do some SQL
text(INSERT INTO insertable SELECT
30 matches
Mail list logo
