On Thursday 12 June 2008 22:44:25 Yannick Gingras wrote:
Greeting Alchemists,
in order to implement schema diffing, it would be nice if two
similar ColumnDefault objects would be comparable as such. I
attach a path to implement such test. Would it make sense to add
this support in
And a related question: What is the general feeling on how well
SQLA abtstracts the underlying database away? Am I expecting too
much to be able to write my application using SQLA-only from the
beginning and have it work on any of the popular databases without
much tweaking?
YMMV. it is
3. What internal SQLA structures can I count on staying fixed
through revisions?
everything changes/can change.
so just do it, and keep doors opened for being version-aware (or
actualy make them later).
i have a lot of this stuff, look in the dbcook sources. e.g. after
rev260 i've whacked
When executing a query on some joined SQLA-mapper, SQLite throws the
following exception (unlike Postgres, which handles it just fine):
OperationalError: (OperationalError) no such column: album.id
Here's the query:
SELECT album.id AS album_id
FROM soup JOIN (album JOIN vinyl ON vinyl.id =
On Thu, Jun 12, 2008 at 4:58 PM, bollwyvl [EMAIL PROTECTED] wrote:
I am running into similar problems, adding to the complexity the
threadpool module.
Here's a post that might help:
http://blog.uxpython.com/blog/web/view/116
I am still running into problems, however, based on parent/child
YMMV. it is actualy you who break things. e.g. if u dont rely much on
specific SQldialect notions, or better, on specific SQL notions,
you'r settled.
i've made dbcook over SA and ever since the team have forgotten about
what SQL is, except some very tricky things which has to be SQL
You seem to have stumbled into the same bug as I have while i fixed the
IN SQL generation code for oracle to work inside the column list, not
just in the where-clause.
I ended up hacking SQLAlchemy/trunk/lib/sqlalchemy/sql/expression.py
like this:
2166
Hi,
I don't think that is a very workable strategy in the long run :( There
are far to many bogus restrictions in some databases, e.g. Oracle, for
any meaningful program to
be written to work on all platforms w/o support/wrapping/hiding of ugly
details by SA.
This is often a difficulty for
On Friday 13 June 2008 16:34:47 Paul Johnston wrote:
Hi,
I don't think that is a very workable strategy in the long run :(
There
are far to many bogus restrictions in some databases, e.g.
Oracle, for any meaningful program to
be written to work on all platforms w/o
On Jun 13, 2008, at 5:43 AM, Malthe Borch wrote:
When executing a query on some joined SQLA-mapper, SQLite throws the
following exception (unlike Postgres, which handles it just fine):
OperationalError: (OperationalError) no such column: album.id
Here's the query:
SELECT album.id AS
On Jun 13, 2008, at 1:00 AM, Russell Warren wrote:
Any help is appreciated. I expect I'm in over my head trying to mess
with a dialect implementation. I'm also worried that this will just
be the first of many things like this I'll be trying to overcome to
get SQLA to truly abstract the
On Jun 13, 2008, at 3:58 AM, Egil Möller wrote:
I and a coworker are currently working on a patch-set to the oracle
driver for SA for this very reason, fixing issues like:
* broken mangling of forbidden/to long table/column names
really ? we have a lot of tests which pass fine for that,
I submitted a temporary tables patch that basically allows you to put
a prefixes keyword when you create the Table():
db = create_engine('sqlite:///')
meta = MetaData()
conn = db.connect()
meta.bind = conn
tbl = Table('foo', meta, Column('bar', Integer),
prefixes=['TEMPORARY'])
meta.create_all()
for example, heres a beast of a unit test:
python test/orm/inheritance/query.py --log-debug=sqlalchemy.engine --
db oracle PolymorphicUnionsTest.test_primary_eager_aliasing
When you run on SQLite, one of the queries is:
SELECT anon_1.people_person_id AS anon_1_people_person_id,
On Jun 13, 2008, at 11:28 AM, vomjom wrote:
I'm wondering though. Will you accept an enhancement that allows you
to use postgresql's COPY in a similar way to how psycopg2 implements
it?
In psycopg2, there are three functions: copy_from, copy_to,
copy_expert
curs.copy_from(io,
Michael Bayer wrote:
sqlite doesn't like the parenthesis. when making the joins with a
SQLA join() construct, you need to make the joins from left to right,
i.e.:
soup.join(album, ...).join(vinyl, ...)
as opposed to:
soup.join(album.join(vinyl, ...), ...)
Actually, we are sort
On Jun 13, 2008, at 12:45 PM, Malthe Borch wrote:
Actually, we are sort of doing this already --except-- due to your
previous advice, we're now using the ``inherits``-option to
automatically have SQLA figure out the correct unit-of-work order.
With this option, the above join results in
if you'd like to specify a value generator for the columns, just use a
ColumnDefault. Whatever function or SQL you like will be called if no
value is present - its just in this case we can't rely upon SQLite's
OID generation.
Thanks - I'll look into that. I just have to figure out how to
so far i have found these ways to hack somebeody else's source:
a) inherit the class, replace whatever, use the new version - works
if it is just you using the new-stuff
b) complete replacement: import thatclass; thatclass.method =
your-own-version
c) partial hacks: inspect.get_source(
19 matches
Mail list logo
