Hi,
I'm connecting to an ancient version of MySQL (3.23.58) that (as far as
I can tell) doesn't support basic JOIN table ON condition syntax
Ie. this gives a syntax error:
SELECT * FROM productversions pv
JOIN producttypes pt ON pv.producttype = pt.producttype
Whereas this is fine:
Felix Schwarz wrote:
Hi,
after reading the docs [1] I thought that something like
session.query(User).filter(User.c.id 3)[0]
should work even if the filter clause does not return any rows.
But - compliant with Python's behavior - SQLAlchemy raises an
IndexError.
(...)
File
Or you could use .limit(1). I've always found that more clear than the
Python indexing notation because I think of it slicing a list, not
applying a limit to a query.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
On further consideration of the interface, what about adding two new
keywords to options() - mapper, and id? That way someone with a large
group of options to set won't have to type the entity name and/or id
on every single option.
session.query(Class).options(options for main
Michael Bayer wrote:
On Dec 11, 2007, at 10:07 AM, King Simon-NFHD78 wrote:
I assume the problem is that my date_created column isn't
immediately
available at the 'after_insert' stage, because it is
generated in the
SQL INSERT statement, but hasn't been read back from the
u.Xs is going to have exactly those X's which have u's id as their
user_id attribute. the X which you appended to u.Ys[0] is from a
different relationship. so yeah you have to set the user_id attribute
on the X, which is entirely legal. However the legit way to do it
is to just add the X
On Dec 12, 2007, at 9:04 AM, King Simon-NFHD78 wrote:
Hi,
I'm connecting to an ancient version of MySQL (3.23.58) that (as far
as
I can tell) doesn't support basic JOIN table ON condition syntax
Ie. this gives a syntax error:
SELECT * FROM productversions pv
JOIN producttypes pt
Michael Bayer wrote
On Dec 12, 2007, at 9:04 AM, King Simon-NFHD78 wrote:
Hi,
I'm connecting to an ancient version of MySQL (3.23.58)
that (as far
as
I can tell) doesn't support basic JOIN table ON
condition syntax
Ie. this gives a syntax error:
SELECT * FROM
King Simon-NFHD78 wrote:
Hi,
I'm connecting to an ancient version of MySQL (3.23.58) that (as far as
I can tell) doesn't support basic JOIN table ON condition syntax
Ie. this gives a syntax error:
SELECT * FROM productversions pv
JOIN producttypes pt ON pv.producttype =
Alexandre Conrad wrote:
Here is the code I'm working on (sqlite and mysql errors at the bottom):
http://rafb.net/p/HlZw3P26.html
Here are the relations for clarity:
client(company) -- one-to-many - site(company)
client(company) -- one-to-many - channel(object)
query == site - client
On Dec 12, 2007, at 10:07 AM, Chris M wrote:
On further consideration of the interface, what about adding two new
keywords to options() - mapper, and id? That way someone with a large
group of options to set won't have to type the entity name and/or id
on every single option.
Jason kirtland wrote:
King Simon-NFHD78 wrote:
Hi,
I'm connecting to an ancient version of MySQL (3.23.58)
that (as far as
I can tell) doesn't support basic JOIN table ON
condition syntax
Ie. this gives a syntax error:
SELECT * FROM productversions pv
JOIN
King Simon-NFHD78 wrote:
Jason kirtland wrote:
King Simon-NFHD78 wrote:
Hi,
I'm connecting to an ancient version of MySQL (3.23.58)
that (as far as
I can tell) doesn't support basic JOIN table ON
condition syntax
This is in r3916. It's a simple change that can be easily monkey
Hey Fabio, would you please post a full non-working copy with the new schema
and all the PKs that you want set up? There are a few too many variants in
this thread to see what's going on now. Your earlier versions didn't include
'station' as a PK, but did include 'start', while this one's the
yeah SQLAlchemy started, like Rick was getting at, with a much closer
to the metal idea than that, that if you made a new object and put it
in the session, youd know that it wasnt flushed yet. My experience
with hibernate is identical, actually, nothing gets generated or
anything in
I'm not on my pc right now so I can send you the non working copy only
tomorrow
I've tried several schemas changes to try and see if the problem
always occurs or if there cases that it works, not necessary because i
need all those schemas In the former table schema, as i said, i've
On Dec 12, 2007, at 4:49 PM, Adam Batkin wrote:
I would think it could be an option on the Table (err, Column) itself
and not a mapper option. Something like pending_flush=True (which can
default to False to keep the current behavior...though that name
probably isn't very good, but
Greetings,
I've tried doing the following using ordering_list for many to many
relations but it didn't work:
post_table = Table('posts', metadata,
Column('id', Integer, primary_key=True),
Column('headline', String(255), nullable=False),
Column('body', String)
)
On Dec 11, 10:55 am, King Simon-NFHD78 [EMAIL PROTECTED]
wrote:
It may not matter to you, but I wouldn't have thought this would be a
very efficient query, because the database is going to have to call the
DATE_FORMAT function twice for every row in your table. I would have
thought a more
19 matches
Mail list logo
