date:20100517

How do I translate the following:

select A.column, V.queried from A, (VALUES ( ('foo'), ('bar') )) as V
(queried) where A.column2 = V.queried;

into sqlalchemy-speak. I'm not using the ORM.

http://www.postgresql.org/docs/8.4/static/sql-values.html


-- 
Jon

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Re: [sqlalchemy] Superfluous SELECT when reusing object after commit

set expire_on_commit=False on your sessionmaker.


On May 17, 2010, at 6:20 AM, Julian Scheid wrote:

 Is there a way to avoid the SELECT statement issued by the following
 test case, i.e. to have some_a survive the commit?
 
 --- 8 ---
 
 from sqlalchemy import create_engine, Column, Integer, String, ForeignKey
 from sqlalchemy.orm import sessionmaker, relation
 from sqlalchemy.ext.declarative import declarative_base
 
 engine = create_engine(sqlite://, echo=True)
 session = sessionmaker(bind=engine)()
 
 Base = declarative_base()
 
 class A(Base):
__tablename__ = 'a'
id = Column(Integer, primary_key=True)
 
 class B(Base):
__tablename__ = 'b'
id = Column(Integer, primary_key=True)
a_id = Column(Integer, ForeignKey('a.id'), nullable = False)
a = relation(A)
 
 Base.metadata.create_all(bind=engine)
 
 some_a = A()
 session.add(some_a)
 session.commit()
 
 some_b = B(a=some_a)
 session.add(some_b)
 session.commit()
 
 --- 8 ---
 
 # Table creation etc omitted
 
 2010-05-17 22:12:06,533 INFO sqlalchemy.engine.base.Engine.0x...41d0 BEGIN
 2010-05-17 22:12:06,534 INFO sqlalchemy.engine.base.Engine.0x...41d0
 INSERT INTO a DEFAULT VALUES
 2010-05-17 22:12:06,534 INFO sqlalchemy.engine.base.Engine.0x...41d0 []
 2010-05-17 22:12:06,534 INFO sqlalchemy.engine.base.Engine.0x...41d0 COMMIT
 2010-05-17 22:12:06,535 INFO sqlalchemy.engine.base.Engine.0x...41d0 BEGIN
 2010-05-17 22:12:06,536 INFO sqlalchemy.engine.base.Engine.0x...41d0
 SELECT a.id AS a_id
 FROM a
 WHERE a.id = ?
   # -- I'd like to avoid this
 2010-05-17 22:12:06,536 INFO sqlalchemy.engine.base.Engine.0x...41d0 [1]
 2010-05-17 22:12:06,537 INFO sqlalchemy.engine.base.Engine.0x...41d0
 INSERT INTO b (a_id) VALUES (?)
 2010-05-17 22:12:06,537 INFO sqlalchemy.engine.base.Engine.0x...41d0 [1]
 2010-05-17 22:12:06,537 INFO sqlalchemy.engine.base.Engine.0x...41d0 COMMIT
 
 --- 8 ---
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 sqlalchemy group.
 To post to this group, send email to sqlalch...@googlegroups.com.
 To unsubscribe from this group, send email to 
 sqlalchemy+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/sqlalchemy?hl=en.
 

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Re: [sqlalchemy] Blob Issue

cx_oracle requires special type handling with BLOB.   You must pass full typing 
information to SQLAlchemy in order to have them handled directly.

The test case below doesn't make sense to me since select([dummy]) would 
render SELECT dummy FROM DUAL, which I didn't think was the same as select * 
from dummy.

In any case, if you are using textual SQL and need typing information, use the 
text() construct, 
http://www.sqlalchemy.org/docs/reference/sqlalchemy/expressions.html#sqlalchemy.sql.expression.text
 , specifying typemap and bindparams as appropriate.

text(select * from dummy where foo=:bar, bindparams=[bindparam('bar', 
type_=String)], typemap={'a':Binary, 'b':String})


On May 17, 2010, at 8:28 AM, dhanil anupurath wrote:

 Hi
 
  I am having a trouble with SA-oracle-Blob datatype.
  Here I have a test program like this.
 
  import pkg_resources
  pkg_resources.require(cx-Oracle=5.0.3)
  import cx_Oracle
  import sqlalchemy
  from sqlalchemy.sql import select
 
 db=sqlalchemy.create_engine('oracle://cse:c...@localhost')
 conn = db.connect()
 
  result=conn.execute(select([dummy]))
  print helloo
  print result.fetchone()
 
  conn.close()
 
 cse is the username and password for ORACLE schema
 
duumy is the table name ,it has a column with datatype BLob.
 
For this am geting the result with the error,
 
ORA-00932: inconsistent datatypes: expected NUMBER got BLOB
 
Is there is any solution so that i do can do more complecated
select statements.
 
   Is Blob not supported for ORACLE-SA
 
   Any help is encouraged.
 
THANKS
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 sqlalchemy group.
 To post to this group, send email to sqlalch...@googlegroups.com.
 To unsubscribe from this group, send email to 
 sqlalchemy+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/sqlalchemy?hl=en.
 

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Re: [sqlalchemy] constant tables / VALUES expression

it is here:

http://groups.google.com/group/sqlalchemy/browse_thread/thread/7f950b628d7ebee5/4421b272d4c7f91f


let me add that to the wiki


On May 17, 2010, at 8:46 AM, Jon Nelson wrote:

 How do I translate the following:
 
 select A.column, V.queried from A, (VALUES ( ('foo'), ('bar') )) as V
 (queried) where A.column2 = V.queried;
 
 into sqlalchemy-speak. I'm not using the ORM.
 
 http://www.postgresql.org/docs/8.4/static/sql-values.html
 
 
 -- 
 Jon
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 sqlalchemy group.
 To post to this group, send email to sqlalch...@googlegroups.com.
 To unsubscribe from this group, send email to 
 sqlalchemy+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/sqlalchemy?hl=en.
 

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Re: [sqlalchemy] constant tables / VALUES expression

On Mon, May 17, 2010 at 8:58 AM, Michael Bayer mike...@zzzcomputing.com wrote:
 it is here:

 http://groups.google.com/group/sqlalchemy/browse_thread/thread/7f950b628d7ebee5/4421b272d4c7f91f


 let me add that to the wiki

Cool!

However, http://www.postgresql.org/docs/8.4/static/sql-values.html
seems to indicate that that is a performance impact of using VALUES
with lots of values.  Does anybody know what lots means? 50,000?
500,000?  14?



-- 
Jon

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Re: [sqlalchemy] constant tables / VALUES expression

On Mon, May 17, 2010 at 8:58 AM, Michael Bayer mike...@zzzcomputing.com wrote:
 it is here:

 http://groups.google.com/group/sqlalchemy/browse_thread/thread/7f950b628d7ebee5/4421b272d4c7f91f


 let me add that to the wiki

The part about the thread that worries me a bit is this:

(%s) % , .join(repr(elem) for elem in tup)

Is there a way to do this using the same parameter escaping mechanism
that the rest of SA uses?
The repr() seems a bit off to me here.

Of course, being able to specify the names of columns would also be
nifty - while it's nice to rely on column1, column2 it's also nice
to get in your result sets the names that one might prefer.

-- 
Jon

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Re: [sqlalchemy] constant tables / VALUES expression


On May 17, 2010, at 10:14 AM, Jon Nelson wrote:

 On Mon, May 17, 2010 at 8:58 AM, Michael Bayer mike...@zzzcomputing.com 
 wrote:
 it is here:
 
 http://groups.google.com/group/sqlalchemy/browse_thread/thread/7f950b628d7ebee5/4421b272d4c7f91f
 
 
 let me add that to the wiki
 
 The part about the thread that worries me a bit is this:
 
(%s) % , .join(repr(elem) for elem in tup)
 
 Is there a way to do this using the same parameter escaping mechanism
 that the rest of SA uses?
 The repr() seems a bit off to me here.
 
 Of course, being able to specify the names of columns would also be
 nifty - while it's nice to rely on column1, column2 it's also nice
 to get in your result sets the names that one might prefer.


The escaping mechanism you speak of is native to the DBAPI, in your case 
psycopg2.I don't believe it has a public API.

We have a slightly better escaping mechanism embedded in the compiler for usage 
with databases that don't allow binds everywhere in the statement.   But we 
have avoided having to build our own escapers for a very long time now as it 
is a contentious area.

Here it is:

def render_literal_value(self, value, type_):
Render the value of a bind parameter as a quoted literal.

This is used for statement sections that do not accept bind paramters
on the target driver/database.

This should be implemented by subclasses using the quoting services
of the DBAPI.


if isinstance(value, basestring):
value = value.replace(', '')
return '%s' % value
elif value is None:
return NULL
elif isinstance(value, (float, int, long)):
return repr(value)
elif isinstance(value, decimal.Decimal):
return str(value)
else:
raise NotImplementedError(Don't know how to literal-quote value 
%r % value)



-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Re: [sqlalchemy] constant tables / VALUES expression

On Mon, May 17, 2010 at 9:32 AM, Michael Bayer mike...@zzzcomputing.com wrote:

 On May 17, 2010, at 10:14 AM, Jon Nelson wrote:

 On Mon, May 17, 2010 at 8:58 AM, Michael Bayer mike...@zzzcomputing.com 
 wrote:
 it is here:

 http://groups.google.com/group/sqlalchemy/browse_thread/thread/7f950b628d7ebee5/4421b272d4c7f91f


 let me add that to the wiki

 The part about the thread that worries me a bit is this:

        (%s) % , .join(repr(elem) for elem in tup)

 Is there a way to do this using the same parameter escaping mechanism
 that the rest of SA uses?
 The repr() seems a bit off to me here.

 Of course, being able to specify the names of columns would also be
 nifty - while it's nice to rely on column1, column2 it's also nice
 to get in your result sets the names that one might prefer.


 The escaping mechanism you speak of is native to the DBAPI, in your case 
 psycopg2.    I don't believe it has a public API.

Exactly.

 We have a slightly better escaping mechanism embedded in the compiler for 
 usage with databases that don't allow binds everywhere in the statement.   
 But we have avoided having to build our own escapers for a very long time 
 now as it is a contentious area.

Hmm. Is there a way to make the VALUES stuff avoid escaping anything
and use the existing interpolation (and escaping) mechanism?

-- 
Jon

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Re: [sqlalchemy] constant tables / VALUES expression

On May 17, 2010, at 10:55 AM, Jon Nelson wrote:

On Mon, May 17, 2010 at 9:32 AM, Michael Bayer mike...@zzzcomputing.com
wrote:

On May 17, 2010, at 10:14 AM, Jon Nelson wrote:

On Mon, May 17, 2010 at 8:58 AM, Michael Bayer mike...@zzzcomputing.com
wrote:
it is here:

http://groups.google.com/group/sqlalchemy/browse_thread/thread/7f950b628d7ebee5/4421b272d4c7f91f

let me add that to the wiki

The part about the thread that worries me a bit is this:

(%s) % , .join(repr(elem) for elem in tup)

Is there a way to do this using the same parameter escaping mechanism
that the rest of SA uses?
The repr() seems a bit off to me here.

Of course, being able to specify the names of columns would also be
nifty - while it's nice to rely on column1, column2 it's also nice
to get in your result sets the names that one might prefer.

The escaping mechanism you speak of is native to the DBAPI, in your case
psycopg2.I don't believe it has a public API.

Exactly.

We have a slightly better escaping mechanism embedded in the compiler for
usage with databases that don't allow binds everywhere in the statement.
But we have avoided having to build our own escapers for a very long time
now as it is a contentious area.

Hmm. Is there a way to make the VALUES stuff avoid escaping anything
and use the existing interpolation (and escaping) mechanism?

when you say existing, if you mean the one native to bind parameters in the
DBAPI, not that I'm aware of. If you mean the one we have in Compiler, yeah
the compiler is passed to the @compiles decorated call so you should be able to
call render_literal_value() from that Compiler object directly.

--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.

[sqlalchemy] is sqlalchemy-migrate the right way to go?

2010-05-17 Thread Chris Withers


Hi All,

I want our production systems to start caring about the versions of 
their schemas. sqlalchemy-migrate was the first project I came across 
which addresses this. What other projects should I look at in this area, 
or is sqlalchemy-migrate the obvious choice?


If it is, how can I, in my application, check what version of the schema 
the current database is? (the idea being that the app will refuse to 
start unless the schema version is that expected by the app)


Related: how can I short circuit this when the database is empty and 
bump the schema version up to the latest for the app? (ie: dev 
instances, where the process is to blow the db away often so no need for 
migration)


cheers,

Chris

--
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Re: [sqlalchemy] is sqlalchemy-migrate the right way to go?


On May 17, 2010, at 1:13 PM, Chris Withers wrote:

 Hi All,
 
 I want our production systems to start caring about the versions of their 
 schemas. sqlalchemy-migrate was the first project I came across which 
 addresses this. What other projects should I look at in this area, or is 
 sqlalchemy-migrate the obvious choice?
 
 If it is, how can I, in my application, check what version of the schema the 
 current database is? (the idea being that the app will refuse to start unless 
 the schema version is that expected by the app)
 
 Related: how can I short circuit this when the database is empty and bump the 
 schema version up to the latest for the app? (ie: dev instances, where the 
 process is to blow the db away often so no need for migration)

sqlalchemy-migrate is the obvious choice.I am also developing a 
micro-migrations system called Alembic (http://bitbucket.org/zzzeek/alembic) in 
conjunction with my current work project but not all features have been 
implemented yet - its expected that I'll be getting them in a more polished 
state in the coming months.  The Migrate project can of course steal any and 
all desireable features and code from Alembic freely as I would like 
sqlalchemy-migrate to remain the default choice.

as for the related issue, I think its best that your setup provide a 
setup-app type of command which generates an initial schema, and embeds the 
current migrate version number.   Here's a snip of a related Pylons websetup.py:

from migrate.versioning.api import version_control, version, upgrade
from migrate.versioning.exceptions import DatabaseAlreadyControlledError

# Create the tables if they aren't there already
meta.Base.metadata.create_all(bind=meta.engine, checkfirst=True)

# setup migrate versioning table if not present
try:
latest_version = version(migrate)
version_control(pylons.config['sqlalchemy.url'], migrate, 
version=latest_version, echo=True)
except DatabaseAlreadyControlledError:
log.info(migrate table already present)

# do any migrate upgrades pending...
upgrade(pylons.config['sqlalchemy.url'], migrate, version=latest_version, 
echo=True)


The migrations system should only be used for changes to an existing schema.   
Other check this before running types of functionality can be accomplished 
similarly.

As a side note, I also have an elaborate monkeypatch to migrate to get it to 
work with transactional DDL.Simple support for transactional DDL is one of 
the goals of the new tool I am writing.   If you're not on Postgresql or 
MS-SQL, then you can't use transactional DDL anyway.

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

[sqlalchemy] Re: is sqlalchemy-migrate the right way to go?

We will definitely also need a migration tool. We've only briefly
looked into the sqlalchemy-migrate tool, but were immediately
disappointed in its apparent requirement to keep versions of the
schema.

In our book, we see the ideal tool as one that doesn't care about
versions: it just looks at the current database schema versus the
schema loaded into sqlalchemy and decides what DDL statements are
needed to bring the current schema inline with what has been loaded
into python.

We understand there are dangers/limitations to this approach, but in
95% of the cases, this is all you need or want.

There is an 'upgrade_db_from_model' which maybe does exactly this, but
our understanding is lacking.

The whole point is to avoid needing to define a single change in two
places.  For example, if I want to add a column to a table and I
require the programmer to remember to place this change in both the
'master' tables.py file *as well as* an incremental schema version
file, I am only asking for trouble that sooner or later someone (or I)
will miss one of the two and end in problems.

Are there any tools that do this (reflect and introspect to create
dynamic DDL upgrade statements)?







On May 17, 1:50 pm, Michael Bayer mike...@zzzcomputing.com wrote:
 On May 17, 2010, at 1:13 PM, Chris Withers wrote:

  Hi All,

  I want our production systems to start caring about the versions of their 
  schemas. sqlalchemy-migrate was the first project I came across which 
  addresses this. What other projects should I look at in this area, or is 
  sqlalchemy-migrate the obvious choice?

  If it is, how can I, in my application, check what version of the schema 
  the current database is? (the idea being that the app will refuse to start 
  unless the schema version is that expected by the app)

  Related: how can I short circuit this when the database is empty and bump 
  the schema version up to the latest for the app? (ie: dev instances, where 
  the process is to blow the db away often so no need for migration)

 sqlalchemy-migrate is the obvious choice.    I am also developing a 
 micro-migrations system called Alembic (http://bitbucket.org/zzzeek/alembic) 
 in conjunction with my current work project but not all features have been 
 implemented yet - its expected that I'll be getting them in a more polished 
 state in the coming months.  The Migrate project can of course steal any and 
 all desireable features and code from Alembic freely as I would like 
 sqlalchemy-migrate to remain the default choice.

 as for the related issue, I think its best that your setup provide a 
 setup-app type of command which generates an initial schema, and embeds the 
 current migrate version number.   Here's a snip of a related Pylons 
 websetup.py:

 from migrate.versioning.api import version_control, version, upgrade
 from migrate.versioning.exceptions import DatabaseAlreadyControlledError

     # Create the tables if they aren't there already
     meta.Base.metadata.create_all(bind=meta.engine, checkfirst=True)

     # setup migrate versioning table if not present
     try:
         latest_version = version(migrate)
         version_control(pylons.config['sqlalchemy.url'], migrate, 
 version=latest_version, echo=True)
     except DatabaseAlreadyControlledError:
         log.info(migrate table already present)

     # do any migrate upgrades pending...
     upgrade(pylons.config['sqlalchemy.url'], migrate, 
 version=latest_version, echo=True)

 The migrations system should only be used for changes to an existing schema.  
  Other check this before running types of functionality can be accomplished 
 similarly.

 As a side note, I also have an elaborate monkeypatch to migrate to get it to 
 work with transactional DDL.    Simple support for transactional DDL is one 
 of the goals of the new tool I am writing.   If you're not on Postgresql or 
 MS-SQL, then you can't use transactional DDL anyway.

 --
 You received this message because you are subscribed to the Google Groups 
 sqlalchemy group.
 To post to this group, send email to sqlalch...@googlegroups.com.
 To unsubscribe from this group, send email to 
 sqlalchemy+unsubscr...@googlegroups.com.
 For more options, visit this group 
 athttp://groups.google.com/group/sqlalchemy?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Re: [sqlalchemy] Re: is sqlalchemy-migrate the right way to go?

there's a tool for Django called South that does this.   But personally I think 
writing a few lines of alter_column() is preferable to a heaping dose of 
schema-guessing magic.


On May 17, 2010, at 3:28 PM, Kent wrote:

 We will definitely also need a migration tool. We've only briefly
 looked into the sqlalchemy-migrate tool, but were immediately
 disappointed in its apparent requirement to keep versions of the
 schema.
 
 In our book, we see the ideal tool as one that doesn't care about
 versions: it just looks at the current database schema versus the
 schema loaded into sqlalchemy and decides what DDL statements are
 needed to bring the current schema inline with what has been loaded
 into python.
 
 We understand there are dangers/limitations to this approach, but in
 95% of the cases, this is all you need or want.
 
 There is an 'upgrade_db_from_model' which maybe does exactly this, but
 our understanding is lacking.
 
 The whole point is to avoid needing to define a single change in two
 places.  For example, if I want to add a column to a table and I
 require the programmer to remember to place this change in both the
 'master' tables.py file *as well as* an incremental schema version
 file, I am only asking for trouble that sooner or later someone (or I)
 will miss one of the two and end in problems.
 
 Are there any tools that do this (reflect and introspect to create
 dynamic DDL upgrade statements)?
 
 
 
 
 
 
 
 On May 17, 1:50 pm, Michael Bayer mike...@zzzcomputing.com wrote:
 On May 17, 2010, at 1:13 PM, Chris Withers wrote:
 
 Hi All,
 
 I want our production systems to start caring about the versions of their 
 schemas. sqlalchemy-migrate was the first project I came across which 
 addresses this. What other projects should I look at in this area, or is 
 sqlalchemy-migrate the obvious choice?
 
 If it is, how can I, in my application, check what version of the schema 
 the current database is? (the idea being that the app will refuse to start 
 unless the schema version is that expected by the app)
 
 Related: how can I short circuit this when the database is empty and bump 
 the schema version up to the latest for the app? (ie: dev instances, where 
 the process is to blow the db away often so no need for migration)
 
 sqlalchemy-migrate is the obvious choice.I am also developing a 
 micro-migrations system called Alembic (http://bitbucket.org/zzzeek/alembic) 
 in conjunction with my current work project but not all features have been 
 implemented yet - its expected that I'll be getting them in a more polished 
 state in the coming months.  The Migrate project can of course steal any and 
 all desireable features and code from Alembic freely as I would like 
 sqlalchemy-migrate to remain the default choice.
 
 as for the related issue, I think its best that your setup provide a 
 setup-app type of command which generates an initial schema, and embeds 
 the current migrate version number.   Here's a snip of a related Pylons 
 websetup.py:
 
 from migrate.versioning.api import version_control, version, upgrade
 from migrate.versioning.exceptions import DatabaseAlreadyControlledError
 
 # Create the tables if they aren't there already
 meta.Base.metadata.create_all(bind=meta.engine, checkfirst=True)
 
 # setup migrate versioning table if not present
 try:
 latest_version = version(migrate)
 version_control(pylons.config['sqlalchemy.url'], migrate, 
 version=latest_version, echo=True)
 except DatabaseAlreadyControlledError:
 log.info(migrate table already present)
 
 # do any migrate upgrades pending...
 upgrade(pylons.config['sqlalchemy.url'], migrate, 
 version=latest_version, echo=True)
 
 The migrations system should only be used for changes to an existing schema. 
   Other check this before running types of functionality can be 
 accomplished similarly.
 
 As a side note, I also have an elaborate monkeypatch to migrate to get it to 
 work with transactional DDL.Simple support for transactional DDL is one 
 of the goals of the new tool I am writing.   If you're not on Postgresql or 
 MS-SQL, then you can't use transactional DDL anyway.
 
 --
 You received this message because you are subscribed to the Google Groups 
 sqlalchemy group.
 To post to this group, send email to sqlalch...@googlegroups.com.
 To unsubscribe from this group, send email to 
 sqlalchemy+unsubscr...@googlegroups.com.
 For more options, visit this group 
 athttp://groups.google.com/group/sqlalchemy?hl=en.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 sqlalchemy group.
 To post to this group, send email to sqlalch...@googlegroups.com.
 To unsubscribe from this group, send email to 
 sqlalchemy+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/sqlalchemy?hl=en.
 

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post

[sqlalchemy] sqla 0.6.0 with oracle 8 (ORA-00907: missing right parenthesis)

After migrating to 0.6, we've got an apparently well running
application for postgres and Oracle 9 or above.  However, as soon as
we connect to an Oracle 8 database, *everything* we attempt ends with
this: oracle error: ORA-00907: missing right parenthesis


Here is an example trying to run a session query...:

 DBSession.query(SystemParameter).all()
12:35:01,294 INFO  [sqlalchemy.engine.base.Engine.0x...5650] SELECT
USER FROM DUAL
12:35:01,294 INFO  [sqlalchemy.engine.base.Engine.0x...5650] {}
Traceback (most recent call last):
  File console, line 1, in module
  File /home/rarch/tg2env/lib/python2.6/site-packages/
SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/query.py, line
1343, in all
return list(self)
  File /home/rarch/trunk/src/appserver/pylotengine/__init__.py, line
73, in __iter__
return Query.__iter__(self)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/query.py, line
1451, in __iter__
return self._execute_and_instances(context)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/query.py, line
1456, in _execute_and_instances
mapper=self._mapper_zero_or_none())
  File /home/rarch/tg2env/lib/python2.6/site-packages/
SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/session.py,
line 736, in execute
return self._connection_for_bind(engine,
close_with_result=True).execute(
  File /home/rarch/tg2env/lib/python2.6/site-packages/
SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/session.py,
line 701, in _connection_for_bind
return self.transaction._connection_for_bind(engine)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/session.py,
line 319, in _connection_for_bind
conn = bind.contextual_connect()
  File /home/rarch/tg2env/lib/python2.6/site-packages/
SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py,
line 1592, in contextual_connect
return self.Connection(self, self.pool.connect(),
close_with_result=close_with_result, **kwargs)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 154,
in connect
return _ConnectionFairy(self).checkout()
  File /home/rarch/tg2env/lib/python2.6/site-packages/
SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 318,
in __init__
rec = self._connection_record = pool.get()
  File /home/rarch/tg2env/lib/python2.6/site-packages/
SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 173,
in get
return self.do_get()
  File /home/rarch/tg2env/lib/python2.6/site-packages/
SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 665,
in do_get
con = self.create_connection()
  File /home/rarch/tg2env/lib/python2.6/site-packages/
SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 134,
in create_connection
return _ConnectionRecord(self)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 214,
in __init__
l.first_connect(self.connection, self)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/engine/
strategies.py, line 145, in first_connect
dialect.initialize(c)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/dialects/oracle/
base.py, line 604, in initialize
super(OracleDialect, self).initialize(connection)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/engine/default.py,
line 138, in initialize
self.returns_unicode_strings =
self._check_unicode_returns(connection)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/engine/default.py,
line 183, in _check_unicode_returns
unicode_for_varchar = check_unicode(sqltypes.VARCHAR(60))
  File /home/rarch/tg2env/lib/python2.6/site-packages/
SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/engine/default.py,
line 173, in check_unicode
]).compile(dialect=self)
DatabaseError: ORA-00907: missing right parenthesis


Any ideas?  Any logging we can enable to help figure this out?

Thanks in advance.

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Re: [sqlalchemy] Re: is sqlalchemy-migrate the right way to go?

2010-05-17 Thread Tamás Bajusz

On Mon, May 17, 2010 at 9:49 PM, Kent k...@retailarchitects.com wrote:
 Ideally, I agree.  Practically speaking, though, we came from a
 company where dozens and dozens of developers worked on the system and
 it was structured exactly this way (a master file and a series of
 incremental upgrade scripts).  It was always getting messed up between
 the two sets of schema definitions until eventually we developed a
 schema comparison tool and all those problems seemed to vanish.

 I'm obviously not saying SQLAlchemy needs to provide this, but just
 trying to make a case for its usefulness.  Thanks for your input.

I'v never tried it, but maybe miruku is what you are looking for:
http://bitbucket.org/gjhiggins/miruku/wiki/Home

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Re: [sqlalchemy] Re: is sqlalchemy-migrate the right way to go?

2010-05-17 Thread Kent Bower


Thanks, that looks like its conceptually what we are hoping for, at least.

On 5/17/2010 3:58 PM, Tamás Bajusz wrote:

On Mon, May 17, 2010 at 9:49 PM, Kentk...@retailarchitects.com  wrote:
   

Ideally, I agree.  Practically speaking, though, we came from a
company where dozens and dozens of developers worked on the system and
it was structured exactly this way (a master file and a series of
incremental upgrade scripts).  It was always getting messed up between
the two sets of schema definitions until eventually we developed a
schema comparison tool and all those problems seemed to vanish.

I'm obviously not saying SQLAlchemy needs to provide this, but just
trying to make a case for its usefulness.  Thanks for your input.
 

I'v never tried it, but maybe miruku is what you are looking for:
http://bitbucket.org/gjhiggins/miruku/wiki/Home

   


--
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Re: [sqlalchemy] sqla 0.6.0 with oracle 8 (ORA-00907: missing right parenthesis)

So there's a call upon first connect which is along the lines of:

SELECT CAST('test unicode returns' AS VARCHAR(60 CHAR)) AS anon_1 FROM DUAL

when you're on oracle 8, it should be checking server version, and coming out 
as:

SELECT CAST('test unicode returns' AS VARCHAR(60)) AS anon_1 FROM DUAL

so step one is make sure the second statement works on Oracle 8.   step two, 
we'd have to make sure the server version detection is working.   you can force 
this particular case like:

engine = create_engine('oracle://...')
engine.dialect.supports_char_length = False

besides that, I'd like to see:


engine = create_engine('oracle://...')
try:
engine.connect()
except:
# because we know its not working
pass
print engine.dialect.server_version_info


this particular interaction doesn't go through regular SQLAlchemy logging.  If 
you really needed to see it occur you'd have to watch your oracle query logs.







On May 17, 2010, at 3:37 PM, Kent wrote:

 After migrating to 0.6, we've got an apparently well running
 application for postgres and Oracle 9 or above.  However, as soon as
 we connect to an Oracle 8 database, *everything* we attempt ends with
 this: oracle error: ORA-00907: missing right parenthesis
 
 
 Here is an example trying to run a session query...:
 
 DBSession.query(SystemParameter).all()
 12:35:01,294 INFO  [sqlalchemy.engine.base.Engine.0x...5650] SELECT
 USER FROM DUAL
 12:35:01,294 INFO  [sqlalchemy.engine.base.Engine.0x...5650] {}
 Traceback (most recent call last):
  File console, line 1, in module
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/query.py, line
 1343, in all
return list(self)
  File /home/rarch/trunk/src/appserver/pylotengine/__init__.py, line
 73, in __iter__
return Query.__iter__(self)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/query.py, line
 1451, in __iter__
return self._execute_and_instances(context)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/query.py, line
 1456, in _execute_and_instances
mapper=self._mapper_zero_or_none())
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/session.py,
 line 736, in execute
return self._connection_for_bind(engine,
 close_with_result=True).execute(
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/session.py,
 line 701, in _connection_for_bind
return self.transaction._connection_for_bind(engine)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/session.py,
 line 319, in _connection_for_bind
conn = bind.contextual_connect()
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py,
 line 1592, in contextual_connect
return self.Connection(self, self.pool.connect(),
 close_with_result=close_with_result, **kwargs)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 154,
 in connect
return _ConnectionFairy(self).checkout()
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 318,
 in __init__
rec = self._connection_record = pool.get()
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 173,
 in get
return self.do_get()
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 665,
 in do_get
con = self.create_connection()
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 134,
 in create_connection
return _ConnectionRecord(self)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 214,
 in __init__
l.first_connect(self.connection, self)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/engine/
 strategies.py, line 145, in first_connect
dialect.initialize(c)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/dialects/oracle/
 base.py, line 604, in initialize
super(OracleDialect, self).initialize(connection)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/engine/default.py,
 line 138, in initialize
self.returns_unicode_strings =
 self._check_unicode_returns(connection)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/engine/default.py,
 line 183, in _check_unicode_returns
unicode_for_varchar

[sqlalchemy] Re: sqla 0.6.0 with oracle 8 (ORA-00907: missing right parenthesis)

Connected to:
Oracle8i Enterprise Edition Release 8.1.7.4.0 - Production
With the Partitioning option
JServer Release 8.1.7.4.0 - Production


Session altered.

SQL SELECT CAST('test unicode returns' AS VARCHAR(60)) AS anon_1 FROM
DUAL
  2  ;

ANON_1

test unicode returns

SQL




On May 17, 4:47 pm, Michael Bayer mike...@zzzcomputing.com wrote:
 So there's a call upon first connect which is along the lines of:

 SELECT CAST('test unicode returns' AS VARCHAR(60 CHAR)) AS anon_1 FROM DUAL

 when you're on oracle 8, it should be checking server version, and coming out 
 as:

 SELECT CAST('test unicode returns' AS VARCHAR(60)) AS anon_1 FROM DUAL

 so step one is make sure the second statement works on Oracle 8.   step two, 
 we'd have to make sure the server version detection is working.   you can 
 force this particular case like:

 engine = create_engine('oracle://...')
 engine.dialect.supports_char_length = False

 besides that, I'd like to see:

 engine = create_engine('oracle://...')
 try:
     engine.connect()
 except:
     # because we know its not working
     pass
 print engine.dialect.server_version_info

 this particular interaction doesn't go through regular SQLAlchemy logging.  
 If you really needed to see it occur you'd have to watch your oracle query 
 logs.

 On May 17, 2010, at 3:37 PM, Kent wrote:



  After migrating to 0.6, we've got an apparently well running
  application for postgres and Oracle 9 or above.  However, as soon as
  we connect to an Oracle 8 database, *everything* we attempt ends with
  this: oracle error: ORA-00907: missing right parenthesis

  Here is an example trying to run a session query...:

  DBSession.query(SystemParameter).all()
  12:35:01,294 INFO  [sqlalchemy.engine.base.Engine.0x...5650] SELECT
  USER FROM DUAL
  12:35:01,294 INFO  [sqlalchemy.engine.base.Engine.0x...5650] {}
  Traceback (most recent call last):
   File console, line 1, in module
   File /home/rarch/tg2env/lib/python2.6/site-packages/
  SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/query.py, line
  1343, in all
     return list(self)
   File /home/rarch/trunk/src/appserver/pylotengine/__init__.py, line
  73, in __iter__
     return Query.__iter__(self)
   File /home/rarch/tg2env/lib/python2.6/site-packages/
  SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/query.py, line
  1451, in __iter__
     return self._execute_and_instances(context)
   File /home/rarch/tg2env/lib/python2.6/site-packages/
  SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/query.py, line
  1456, in _execute_and_instances
     mapper=self._mapper_zero_or_none())
   File /home/rarch/tg2env/lib/python2.6/site-packages/
  SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/session.py,
  line 736, in execute
     return self._connection_for_bind(engine,
  close_with_result=True).execute(
   File /home/rarch/tg2env/lib/python2.6/site-packages/
  SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/session.py,
  line 701, in _connection_for_bind
     return self.transaction._connection_for_bind(engine)
   File /home/rarch/tg2env/lib/python2.6/site-packages/
  SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/session.py,
  line 319, in _connection_for_bind
     conn = bind.contextual_connect()
   File /home/rarch/tg2env/lib/python2.6/site-packages/
  SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py,
  line 1592, in contextual_connect
     return self.Connection(self, self.pool.connect(),
  close_with_result=close_with_result, **kwargs)
   File /home/rarch/tg2env/lib/python2.6/site-packages/
  SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 154,
  in connect
     return _ConnectionFairy(self).checkout()
   File /home/rarch/tg2env/lib/python2.6/site-packages/
  SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 318,
  in __init__
     rec = self._connection_record = pool.get()
   File /home/rarch/tg2env/lib/python2.6/site-packages/
  SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 173,
  in get
     return self.do_get()
   File /home/rarch/tg2env/lib/python2.6/site-packages/
  SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 665,
  in do_get
     con = self.create_connection()
   File /home/rarch/tg2env/lib/python2.6/site-packages/
  SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 134,
  in create_connection
     return _ConnectionRecord(self)
   File /home/rarch/tg2env/lib/python2.6/site-packages/
  SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 214,
  in __init__
     l.first_connect(self.connection, self)
   File /home/rarch/tg2env/lib/python2.6/site-packages/
  SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/engine/
  strategies.py, line 145, in first_connect
     dialect.initialize(c)
   File /home/rarch/tg2env/lib/python2.6/site-packages/
  SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/dialects/oracle/

[sqlalchemy] Re: sqla 0.6.0 with oracle 8 (ORA-00907: missing right parenthesis)

Sorry, posted too quickly, I'll get the rest of the results you asked
about...




On May 17, 4:56 pm, Kent k...@retailarchitects.com wrote:
 Connected to:
 Oracle8i Enterprise Edition Release 8.1.7.4.0 - Production
 With the Partitioning option
 JServer Release 8.1.7.4.0 - Production

 Session altered.

 SQL SELECT CAST('test unicode returns' AS VARCHAR(60)) AS anon_1 FROM
 DUAL
   2  ;

 ANON_1
 
 test unicode returns

 SQL

 On May 17, 4:47 pm, Michael Bayer mike...@zzzcomputing.com wrote:



  So there's a call upon first connect which is along the lines of:

  SELECT CAST('test unicode returns' AS VARCHAR(60 CHAR)) AS anon_1 FROM DUAL

  when you're on oracle 8, it should be checking server version, and coming 
  out as:

  SELECT CAST('test unicode returns' AS VARCHAR(60)) AS anon_1 FROM DUAL

  so step one is make sure the second statement works on Oracle 8.   step 
  two, we'd have to make sure the server version detection is working.   you 
  can force this particular case like:

  engine = create_engine('oracle://...')
  engine.dialect.supports_char_length = False

  besides that, I'd like to see:

  engine = create_engine('oracle://...')
  try:
      engine.connect()
  except:
      # because we know its not working
      pass
  print engine.dialect.server_version_info

  this particular interaction doesn't go through regular SQLAlchemy logging.  
  If you really needed to see it occur you'd have to watch your oracle query 
  logs.

  On May 17, 2010, at 3:37 PM, Kent wrote:

   After migrating to 0.6, we've got an apparently well running
   application for postgres and Oracle 9 or above.  However, as soon as
   we connect to an Oracle 8 database, *everything* we attempt ends with
   this: oracle error: ORA-00907: missing right parenthesis

   Here is an example trying to run a session query...:

   DBSession.query(SystemParameter).all()
   12:35:01,294 INFO  [sqlalchemy.engine.base.Engine.0x...5650] SELECT
   USER FROM DUAL
   12:35:01,294 INFO  [sqlalchemy.engine.base.Engine.0x...5650] {}
   Traceback (most recent call last):
    File console, line 1, in module
    File /home/rarch/tg2env/lib/python2.6/site-packages/
   SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/query.py, line
   1343, in all
      return list(self)
    File /home/rarch/trunk/src/appserver/pylotengine/__init__.py, line
   73, in __iter__
      return Query.__iter__(self)
    File /home/rarch/tg2env/lib/python2.6/site-packages/
   SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/query.py, line
   1451, in __iter__
      return self._execute_and_instances(context)
    File /home/rarch/tg2env/lib/python2.6/site-packages/
   SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/query.py, line
   1456, in _execute_and_instances
      mapper=self._mapper_zero_or_none())
    File /home/rarch/tg2env/lib/python2.6/site-packages/
   SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/session.py,
   line 736, in execute
      return self._connection_for_bind(engine,
   close_with_result=True).execute(
    File /home/rarch/tg2env/lib/python2.6/site-packages/
   SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/session.py,
   line 701, in _connection_for_bind
      return self.transaction._connection_for_bind(engine)
    File /home/rarch/tg2env/lib/python2.6/site-packages/
   SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/session.py,
   line 319, in _connection_for_bind
      conn = bind.contextual_connect()
    File /home/rarch/tg2env/lib/python2.6/site-packages/
   SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py,
   line 1592, in contextual_connect
      return self.Connection(self, self.pool.connect(),
   close_with_result=close_with_result, **kwargs)
    File /home/rarch/tg2env/lib/python2.6/site-packages/
   SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 154,
   in connect
      return _ConnectionFairy(self).checkout()
    File /home/rarch/tg2env/lib/python2.6/site-packages/
   SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 318,
   in __init__
      rec = self._connection_record = pool.get()
    File /home/rarch/tg2env/lib/python2.6/site-packages/
   SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 173,
   in get
      return self.do_get()
    File /home/rarch/tg2env/lib/python2.6/site-packages/
   SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 665,
   in do_get
      con = self.create_connection()
    File /home/rarch/tg2env/lib/python2.6/site-packages/
   SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 134,
   in create_connection
      return _ConnectionRecord(self)
    File /home/rarch/tg2env/lib/python2.6/site-packages/
   SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 214,
   in __init__
      l.first_connect(self.connection, self)
    File /home/rarch/tg2env/lib/python2.6/site-packages/

Re: [sqlalchemy] Re: sqla 0.6.0 with oracle 8 (ORA-00907: missing right parenthesis)

what do you get for engine.dialect.supports_char_length, 
engine.dialect.server_version_info ?


On May 17, 2010, at 4:56 PM, Kent wrote:

 Connected to:
 Oracle8i Enterprise Edition Release 8.1.7.4.0 - Production
 With the Partitioning option
 JServer Release 8.1.7.4.0 - Production
 
 
 Session altered.
 
 SQL SELECT CAST('test unicode returns' AS VARCHAR(60)) AS anon_1 FROM
 DUAL
  2  ;
 
 ANON_1
 
 test unicode returns
 
 SQL
 
 
 
 
 On May 17, 4:47 pm, Michael Bayer mike...@zzzcomputing.com wrote:
 So there's a call upon first connect which is along the lines of:
 
 SELECT CAST('test unicode returns' AS VARCHAR(60 CHAR)) AS anon_1 FROM DUAL
 
 when you're on oracle 8, it should be checking server version, and coming 
 out as:
 
 SELECT CAST('test unicode returns' AS VARCHAR(60)) AS anon_1 FROM DUAL
 
 so step one is make sure the second statement works on Oracle 8.   step two, 
 we'd have to make sure the server version detection is working.   you can 
 force this particular case like:
 
 engine = create_engine('oracle://...')
 engine.dialect.supports_char_length = False
 
 besides that, I'd like to see:
 
 engine = create_engine('oracle://...')
 try:
 engine.connect()
 except:
 # because we know its not working
 pass
 print engine.dialect.server_version_info
 
 this particular interaction doesn't go through regular SQLAlchemy logging.  
 If you really needed to see it occur you'd have to watch your oracle query 
 logs.
 
 On May 17, 2010, at 3:37 PM, Kent wrote:
 
 
 
 After migrating to 0.6, we've got an apparently well running
 application for postgres and Oracle 9 or above.  However, as soon as
 we connect to an Oracle 8 database, *everything* we attempt ends with
 this: oracle error: ORA-00907: missing right parenthesis
 
 Here is an example trying to run a session query...:
 
 DBSession.query(SystemParameter).all()
 12:35:01,294 INFO  [sqlalchemy.engine.base.Engine.0x...5650] SELECT
 USER FROM DUAL
 12:35:01,294 INFO  [sqlalchemy.engine.base.Engine.0x...5650] {}
 Traceback (most recent call last):
  File console, line 1, in module
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/query.py, line
 1343, in all
return list(self)
  File /home/rarch/trunk/src/appserver/pylotengine/__init__.py, line
 73, in __iter__
return Query.__iter__(self)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/query.py, line
 1451, in __iter__
return self._execute_and_instances(context)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/query.py, line
 1456, in _execute_and_instances
mapper=self._mapper_zero_or_none())
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/session.py,
 line 736, in execute
return self._connection_for_bind(engine,
 close_with_result=True).execute(
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/session.py,
 line 701, in _connection_for_bind
return self.transaction._connection_for_bind(engine)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/session.py,
 line 319, in _connection_for_bind
conn = bind.contextual_connect()
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/engine/base.py,
 line 1592, in contextual_connect
return self.Connection(self, self.pool.connect(),
 close_with_result=close_with_result, **kwargs)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 154,
 in connect
return _ConnectionFairy(self).checkout()
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 318,
 in __init__
rec = self._connection_record = pool.get()
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 173,
 in get
return self.do_get()
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 665,
 in do_get
con = self.create_connection()
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 134,
 in create_connection
return _ConnectionRecord(self)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/pool.py, line 214,
 in __init__
l.first_connect(self.connection, self)
  File /home/rarch/tg2env/lib/python2.6/site-packages/
 SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/engine/
 strategies.py, line 145, in first_connect
dialect.initialize(c)
  File

[sqlalchemy] Re: sqla 0.6.0 with oracle 8 (ORA-00907: missing right parenthesis)

I think it is using the other select:

Connected to:
Oracle8i Enterprise Edition Release 8.1.7.4.0 - Production
With the Partitioning option
JServer Release 8.1.7.4.0 - Production


Session altered.

SQL SELECT CAST('test unicode returns' AS VARCHAR(60 CHAR)) AS anon_1
FROM DUAL
  2  ;
SELECT CAST('test unicode returns' AS VARCHAR(60 CHAR)) AS anon_1 FROM
DUAL
 *
ERROR at line 1:
ORA-00907: missing right parenthesis


It seems to be detecting the version correctly:

---
from sqlalchemy import *

engine = create_engine('oracle://user:p...@ipaddress:1521/live?
use_ansi=False',echo=True)
try:
engine.connect()
except:
# because we know its not working
print 'exception caught'
print engine.dialect.server_version_info


(tg2env)[ra...@eld appserver]$ python ora8.py
2010-05-17 14:08:39,339 INFO sqlalchemy.engine.base.Engine.0x...db50
SELECT USER FROM DUAL
2010-05-17 14:08:39,344 INFO sqlalchemy.engine.base.Engine.0x...db50
{}
exception caught
(8, 1, 7, 4, 0)
---


Setting 'engine.dialect.supports_char_length = False' causes
ORA-12704: character set mismatch

=
try:
engine.dialect.supports_char_length = False
engine.connect()
except Exception as e:
# because we know its not working
print str(e)
print engine.dialect.server_version_info
=

2010-05-17 14:13:55,687 INFO sqlalchemy.engine.base.Engine.0x...fb50
SELECT USER FROM DUAL
2010-05-17 14:13:55,690 INFO sqlalchemy.engine.base.Engine.0x...fb50
{}
ORA-12704: character set mismatch

(8, 1, 7, 4, 0)



On May 17, 4:58 pm, Kent k...@retailarchitects.com wrote:
 Sorry, posted too quickly, I'll get the rest of the results you asked
 about...

 On May 17, 4:56 pm, Kent k...@retailarchitects.com wrote:



  Connected to:
  Oracle8i Enterprise Edition Release 8.1.7.4.0 - Production
  With the Partitioning option
  JServer Release 8.1.7.4.0 - Production

  Session altered.

  SQL SELECT CAST('test unicode returns' AS VARCHAR(60)) AS anon_1 FROM
  DUAL
    2  ;

  ANON_1
  
  test unicode returns

  SQL

  On May 17, 4:47 pm, Michael Bayer mike...@zzzcomputing.com wrote:

   So there's a call upon first connect which is along the lines of:

   SELECT CAST('test unicode returns' AS VARCHAR(60 CHAR)) AS anon_1 FROM 
   DUAL

   when you're on oracle 8, it should be checking server version, and coming 
   out as:

   SELECT CAST('test unicode returns' AS VARCHAR(60)) AS anon_1 FROM DUAL

   so step one is make sure the second statement works on Oracle 8.   step 
   two, we'd have to make sure the server version detection is working.   
   you can force this particular case like:

   engine = create_engine('oracle://...')
   engine.dialect.supports_char_length = False

   besides that, I'd like to see:

   engine = create_engine('oracle://...')
   try:
       engine.connect()
   except:
       # because we know its not working
       pass
   print engine.dialect.server_version_info

   this particular interaction doesn't go through regular SQLAlchemy 
   logging.  If you really needed to see it occur you'd have to watch your 
   oracle query logs.

   On May 17, 2010, at 3:37 PM, Kent wrote:

After migrating to 0.6, we've got an apparently well running
application for postgres and Oracle 9 or above.  However, as soon as
we connect to an Oracle 8 database, *everything* we attempt ends with
this: oracle error: ORA-00907: missing right parenthesis

Here is an example trying to run a session query...:

DBSession.query(SystemParameter).all()
12:35:01,294 INFO  [sqlalchemy.engine.base.Engine.0x...5650] SELECT
USER FROM DUAL
12:35:01,294 INFO  [sqlalchemy.engine.base.Engine.0x...5650] {}
Traceback (most recent call last):
 File console, line 1, in module
 File /home/rarch/tg2env/lib/python2.6/site-packages/
SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/query.py, line
1343, in all
   return list(self)
 File /home/rarch/trunk/src/appserver/pylotengine/__init__.py, line
73, in __iter__
   return Query.__iter__(self)
 File /home/rarch/tg2env/lib/python2.6/site-packages/
SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/query.py, line
1451, in __iter__
   return self._execute_and_instances(context)
 File /home/rarch/tg2env/lib/python2.6/site-packages/
SQLAlchemy-0.6.0-py2.6-linux-x86_64.egg/sqlalchemy/orm/query.py, line
1456, in _execute_and_instances
   mapper=self._mapper_zero_or_none())
 File /home/rarch/tg2env/lib/python2.6/site-packages/

Re: [sqlalchemy] is sqlalchemy-migrate the right way to go?

2010-05-17 Thread Chris Withers


Michael Bayer wrote:
sqlalchemy-migrate is the obvious choice.I am also developing a micro-migrations system called Alembic (http://bitbucket.org/zzzeek/alembic) 


If we start with sqlalchemy-migrate, do you reckon switching to Alembic 
when it's mature would be feasible?


Chris

--
Simplistix - Content Management, Batch Processing  Python Consulting
   - http://www.simplistix.co.uk

--
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Re: [sqlalchemy] is sqlalchemy-migrate the right way to go?