--On 6. Juli 2007 23:27:30 + jose <[EMAIL PROTECTED]> wrote:
I've got a question that I can't find the answer to. I have a table
called seminars with a date field in it to hold the seminar dates. I
want to query the table to find all the dates for a specific year. I
tried query(Seminars
I've got a question that I can't find the answer to. I have a table
called seminars with a date field in it to hold the seminar dates. I
want to query the table to find all the dates for a specific year. I
tried query(Seminars).filter(Seminars.c.date.year==2007) but this gave
me an error stating
On Jul 6, 2007, at 5:50 PM, Koen Bok wrote:
>
> I have a strange situation. If someone _really_ needs to know why I
> could explain.
>
> When an object gets deleted by SQLAlchemy, it's related objects are
> getting updated setting their foreign keys referring to the deleted
> items to NULL. But
I have a strange situation. If someone _really_ needs to know why I
could explain.
When an object gets deleted by SQLAlchemy, it's related objects are
getting updated setting their foreign keys referring to the deleted
items to NULL. But what if I don't want that to happen? Viewonly is
not an opt
I just wrote this but haven't had time to carefully proof it...if
people have corrections / comments let me know. the intro and all
about executing are rewritten:
http://www.sqlalchemy.org/docs_new/dbengine.html
as well as some changes to "metadata", no more BoundMetaData/
DynamicMetaData:
htt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 5, 2007, at 6:00 PM, Michael Bayer wrote:
> On Jul 5, 5:46 pm, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> What I mean by that is that Mailman has at least three separate
>> related collections of data: mailing lists, users, and messages. It
>
On Jul 6, 7:06 am, Nick <[EMAIL PROTECTED]> wrote:
> thanks, but that didn't work either. In the end i changed the func. call> to a datetime.datetime.now() python call which seems to work. I
> also noticed that i had to change all my date inserts to datetime
> objects as well (previously i was us
On Jul 6, 4:33 am, mc <[EMAIL PROTECTED]> wrote:
> I am using 0.3.6 and reading the 0.3 doc.
>
> The problem is that actually I need it the way it works for me now,
> i.e. returning the auto_increment fields and not my primary key
> fields.
> Will upgrading sqlalchemy break this (undocumented)
--On 6. Juli 2007 11:15:38 -0400 Michael Bayer <[EMAIL PROTECTED]>
wrote:
On Jul 6, 2007, at 6:25 AM, Andreas Jung wrote:
I have a self-referential mapper where a view is involved within a
primaryjoin of a relation. Traversing a tree represented through
the mapper generates a bunch of U
On Jul 6, 2007, at 6:25 AM, Andreas Jung wrote:
>
> I have a self-referential mapper where a view is involved within a
> primaryjoin of a relation. Traversing a tree represented through
> the mapper generates a bunch of UPDATE operations on the view (no
> idea why
> so far) although only S
On Jul 6, 2007, at 6:25 AM, Andreas Jung wrote:
>
> I have a self-referential mapper where a view is involved within a
> primaryjoin of a relation. Traversing a tree represented through
> the mapper generates a bunch of UPDATE operations on the view (no
> idea why
> so far) although only S
On Jul 6, 2007, at 4:33 AM, mc wrote:
>
> I am using 0.3.6 and reading the 0.3 doc.
>
> The problem is that actually I need it the way it works for me now,
> i.e. returning the auto_increment fields and not my primary key
> fields.
> Will upgrading sqlalchemy break this (undocumented) feature?
I noticed that Session has no method len. Wouldn't it be useful to add
one, like this:
--- orm/session.py 2007-07-06 14:38:22.0 +0200
+++ orm/session.py.orig 2007-07-06 14:43:48.0 +0200
@@ -642,6 +642,9 @@
def __iter__(self):
return iter(list(self.uow.new) +
sel
thanks, but that didn't work either. In the end i changed the func. to a datetime.datetime.now() python call which seems to work. I
also noticed that i had to change all my date inserts to datetime
objects as well (previously i was using postgres and inserted dates as
date strings i.e. '2007-01-01
Clear()ing the session before the mandatory commit resolved the issue
(more a workaround than a solution :->).
Andreas
--On 6. Juli 2007 12:25:25 +0200 Andreas Jung <[EMAIL PROTECTED]> wrote:
I have a self-referential mapper where a view is involved within a
primaryjoin of a relation. Travers
I have a self-referential mapper where a view is involved within a
primaryjoin of a relation. Traversing a tree represented through the mapper
generates a bunch of UPDATE operations on the view (no idea why
so far) although only SELECT operations are used during the query.
However views in Pos
SQLAlchemy Column objects override the '==' operator (and many others as
well) so that python expressions get converted to appropriate SQL
expressions.
It's mentioned (briefly) here:
http://www.sqlalchemy.org/docs/sqlconstruction.html#sql_whereclause
Hope that helps,
Simon
> -Original
I must be missing something
Doesn't that evaluate the == expressions and result in an expression
like and_(True, True, False, ...) ?
On Jul 4, 1:04 am, Michael Bayer <[EMAIL PROTECTED]> wrote:
> On Jul 3, 4:06 pm, mc <[EMAIL PROTECTED]> wrote:
>
> > I managed to avoid this issues because for sel
I am using 0.3.6 and reading the 0.3 doc.
The problem is that actually I need it the way it works for me now,
i.e. returning the auto_increment fields and not my primary key
fields.
Will upgrading sqlalchemy break this (undocumented) feature?
On Jul 4, 12:58 am, Michael Bayer <[EMAIL PROTECTED]
19 matches
Mail list logo
