(
AbstractConcreteAbstraction.something.has(id=1)).all()
On Feb 27, 2013, at 8:06 PM, Derek Litz litzo...@gmail.com javascript:
wrote:
Having fun with AbstractBaseClasses tonight :) ... Anyways am I missing
something here as well?
I tried playing with querying the AbstractBaseClass and filtering
Python 2.7.3 (default, Jan 4 2013, 14:06:23)
[GCC 4.2.1 Compatible Apple Clang 4.1 ((tags/Apple/clang-421.11.66))] on
darwin
Type help, copyright, credits or license for more information.
import sqlalchemy
print sqlalchemy.__version__
0.8.0b2
Below is the code I was able to use to reproduce a
other
mappers configure themselves. In the absence of such an event,
call sqlalchemy.orm.configure_mappers() when all subclasses of
AbstractConcreteAbstraction have been declared to force this process to
occur.
On Feb 27, 2013, at 6:57 PM, Derek Litz litzo...@gmail.com javascript
Having fun with AbstractBaseClasses tonight :) ... Anyways am I missing
something here as well?
I tried playing with querying the AbstractBaseClass and filtering on sub
classes but that just produced
a query that did not execute.
from sqlalchemy.engine import Engine
from sqlalchemy import
Code is below: see NOTE comments
from sqlalchemy import create_engine
from sqlalchemy import Column, Integer, Unicode
from sqlalchemy.orm import sessionmaker
from sqlalchemy.ext.declarative import declarative_base
from contextlib import contextmanager
USERNAME = u'root'
PASSWORD = u''
LOCAL_DB
be on. Thank you for
the insight.
On Thursday, January 17, 2013 9:38:26 AM UTC-6, Michael Bayer wrote:
On Jan 17, 2013, at 10:27 AM, Derek Litz wrote:
with mysql_session() as s:
new_user = User(first_name=u'Derek')
s.add(new_user)
s.commit()
add_last_name
, Derek Litz wrote:
So the earlier commit ended the transaction but immediately began a new
one, that's why a second call to commit had a different behavior? I made
the mistake of thinking that the session would be in a similar state to
when I originally acquired it, however, this is not true
,
before add_last_name() gets called.
On Jan 17, 2013, at 10:59 AM, Derek Litz wrote:
So the earlier commit ended the transaction but immediately began a new
one, that's why a second call to commit had a different behavior? I made
the mistake of thinking that the session would
18, 2012 6:09:24 PM UTC-5, Michael Bayer wrote:
On Sep 18, 2012, at 11:38 AM, Derek Litz wrote:
A session when closed, commited, or rolled back, releases the database
connection it acquired from the pool. The session can grab a new
connection later on as needed. Also, many objects
Based on the error message I would guess this is a problem with your
install of Microsoft's SQL Native Client for odbc. Sorry, not a windows
guy, so all I can provide is a link
http://msdn.microsoft.com/en-us/library/ms131321.aspx.
Is your dev MS native client the same as the prod MS native
Good news! I was able to reproduce the exception after modifying your test
script. Attached is my info and the script.
Below is also repeated at the beginning of the two files.
NOTE: You will need to edit connect_to_mssql()
I was able to get the following error using this script.
, though you'll have to
confirm it's working with that rather extreme trigger you have there.
http://hg.sqlalchemy.org/sqlalchemy/archive/default.tar.gz
Why not remove the IDENTITY directive from that column, since you're not
using IDENTITY anyway?
On Apr 5, 2012, at 11:46 AM, Derek Litz
Hello,
First time using sqlalchemy against a table with triggers and it doesn't
seem usable. Can anyone confirm or deny my situation as a bug, or
enlighten me to my user error?
First I ran into this issue:
ERROR:root:Database Error
Traceback (most recent call last):
*File my_code...*
13 matches
Mail list logo