in pre_exec by the column default, which (I believe) is
running the func in sqlite and returning the results, which I'd think
should wind up with a datetime.datetime. I'll try to put together a
minimal test case that shows what's happening.
JP
Yup, that fixed things. Thanks!
On Aug 16, 10:49 am, Michael Bayer [EMAIL PROTECTED] wrote:
ok thats in r3322
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to
doing something wrong all along and only 0.4 is catching it?
JP
--~--~-~--~~~---~--~~
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
', catalog, autoload=True)
catalog.bind = datasource
catalog.bind = 'sqlite:///'
+1
Catalog is, I think, the name we were all trying to come up with back
when metadata first appeared. Really makes it clear what the function
of the object is. Very nice.
JP
-friendly web app. Minimal overhead, maximal flexibility.
meta.connect(uri, threadlocal=True) or meta.connect_threadlocal(uri)
would be ok, but I think worse as an API since they put too much
responsibility on the caller and cause too much repetition.
JP
I filed a ticket with a patch:
http://www.sqlalchemy.org/trac/ticket/505
JP
On Mar 7, 11:17 am, Michael Bayer [EMAIL PROTECTED] wrote:
OK its looking like having it as positional might just be what they
all commonly had in mind...
On Mar 7, 2007, at 5:15 AM, Tim Golden wrote:
On Mar 6
more sense this time...
JP
On Feb 12, 12:42 am, Michael Bayer [EMAIL PROTECTED] wrote:
im confused. the django thread seems to be saying that it is setting
psycopg2 *into* autocommit mode, which causes the problem; the default
setting of autocommit for DBAPI (and maintained in SA) is False
have an example that I think illustrates what I'm talking about
pretty well, so I'm going to file a ticket and attach the example and
the postgres query log I see when I run it. Hopefully that will clear
things up one way or another.
JP
--~--~-~--~~~---~--~~
You
be interested in a patch that implemented that
behavior? Does anyone disagree that that would be better?
JP
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email
example.
Should I file a ticket for the _data_appender error? What else can I do
to help track it down?
JP
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email
trunk. Both of those are likely to take a few days, time is a bit tight
this week.
JP
On Jan 24, 11:41 am, Michael Bayer [EMAIL PROTECTED] wrote:
see, i wish folks would use the trunk more. yeah, file tickets, and
every bug fixed becomes a unit test. this one seems like something
trivial
able to reproduce the error outside of the
full context.
JP
On Jan 24, 12:44 pm, Michael Bayer [EMAIL PROTECTED] wrote:
OK we have a lot of tests that pass with assign_mapper...can you give
me a little more of a test case for 438 ? its a weird error since
not much has changed with attributes
on backrefs like this one, since (I
think) the backref doesn't exist when assign_mapper is monkeypatching
the domain model class.
JP
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post
', user=me)
If that seems interesting to others, I can probably whip up a patch
this weekend (though it's been a while since I got my hands dirty on
the insides of sqlalchemy).
JP
--~--~-~--~~~---~--~~
You received this message because you are subscribed
14 matches
Mail list logo
