[sqlalchemy] Re: Comparable ColumnDefaults for shema diffing
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 Alchemy's core or should a schema diffing library add it through monkey patching? dont rely on things having __eq__, as it may not be your notion of what equality is (type/value/metadata/whatever). u may use SA to traverse the tree as it knows best what the structure is but do all the comparisons yourself. --~--~-~--~~~---~--~~ 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 this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: sqlite PK autoincrement not working when you do a composite PK?
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 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 aware, as they rely on DB-structure being what it is. But dialects... only come to play when something is not supported, and my way of handling this so far is to avoid using any stuff that is not supported everywhere - workaround on lowe or higher level, including model refactoring. --~--~-~--~~~---~--~~ 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 this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: sqlite PK autoincrement not working when you do a composite PK?
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 0.3/0.4beta1 support out. --~--~-~--~~~---~--~~ 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 this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Absurd operational error in SQLite
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 = album.id) ON vinyl.id = soup.id How would you interpret this? Help much appreciated. \malthe --~--~-~--~~~---~--~~ 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 this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Object is already attached to session
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 relationships... i think the answer lies in the sqlalchemy `cascade` property, but I as yet have not found a way to modify that directly in the Elixir layer. I'm not sure the cascade property is the answer to Matt's problem but in any case, you can use the cascade argument on Elixir relationships exactly as you do with SQLAlchemy's relation(). In fact any argument not specifically used by Elixir's relationships is forwarded to the relation() construct. -- Gaëtan de Menten http://openhex.org --~--~-~--~~~---~--~~ 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 this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: sqlite PK autoincrement not working when you do a composite PK?
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 aware, as they rely on DB-structure being what it is. But dialects... only come to play when something is not supported, and my way of handling this so far is to avoid using any stuff that is not supported everywhere - workaround on lowe or higher level, including model refactoring 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. 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 * missing support for the BOOL data type * missing support for boolean expressions in the column list ( select([tbl.c.col1 == tbl.c.col2]) ) (related to the last one above) You might think that you could easily get around the name-length barrier using the shortnames-option. But SA combines table names with column names to form aliases in select column lists, and the length quickly exceeds 32 characters (Oracles limit). In addition, do _you_ know which words are forbidden as column names in Oracle? I can assure you that there is at least a few you don't remember (and I wouldn't remember either :P)... Just a point of measurement (ok, oracle is the worst one...) Best regards, Egil signature.asc Description: OpenPGP digital signature
[sqlalchemy] Re: unexpected behaviour of in_
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 https://projects.freecode.no/internal/projects/browser/div4/div4c/software/SQLAlchemy/trunk/lib/sqlalchemy/sql/expression.py#L2166 *class* _BinaryExpression(ColumnElement): ... 2181 https://projects.freecode.no/internal/projects/browser/div4/div4c/software/SQLAlchemy/trunk/lib/sqlalchemy/sql/expression.py#L2181 *def* *_get_from_objects*(self, **modifiers): 2182 https://projects.freecode.no/internal/projects/browser/div4/div4c/software/SQLAlchemy/trunk/lib/sqlalchemy/sql/expression.py#L2182 res = self.left._get_from_objects(**modifiers) 2183 https://projects.freecode.no/internal/projects/browser/div4/div4c/software/SQLAlchemy/trunk/lib/sqlalchemy/sql/expression.py#L2183 *if* self.operator *is* operators.in_op: *return* res 2184 https://projects.freecode.no/internal/projects/browser/div4/div4c/software/SQLAlchemy/trunk/lib/sqlalchemy/sql/expression.py#L2184 *return* res + self.right._get_from_objects(**modifiers) That seems to do the trick :) Best regards, Egil casbon wrote: Hi All, I am seeing something I didn't expect using in_. Here is a simple example, exactly as I expect: In [13]: col = Trade.c.TradeId.in_([1,2]) In [14]: sel = select([col]) In [15]: print col Trade.TradeId IN (?, ?) In [16]: print sel SELECT Trade.TradeId IN (?, ?) AS anon_1 FROM Trade But now, if I use a subselect, I see a problem: In [17]: col = Trade.c.TradeId.in_(select([Trade.c.TradeId])) In [18]: sel = select([col]) In [19]: print col Trade.TradeId IN (SELECT Trade.TradeId FROM Trade) In [20]: print sel SELECT Trade.TradeId IN (SELECT Trade.TradeId FROM Trade) AS anon_1 FROM Trade, (SELECT Trade.TradeId AS TradeId FROM Trade) The column definition (col) is as expected, but the select definition (sel) is strange. It selects two things and generates n^2 rows. How can I get the select I expect: SELECT Trade.TradeId IN (SELECT Trade.TradeId FROM Trade) AS anon_1 FROM Trade thanks, James --~--~-~--~~~---~--~~ 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 this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~--- signature.asc Description: OpenPGP digital signature
[sqlalchemy] Re: sqlite PK autoincrement not working when you do a composite PK?
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 libraries that provide a portable layer over different implementations. GUI toolkits are a good example. The library essentially has three choices: 1) Only expose functionality that exists on all the implementations 2) Expose the user to the slight differences between implementations 3) Expose consistent functionality, and where an implementation lacks support, fake it In practice, (1) is usually a poor option as it's too restrictive. SQLAlchemy currently takes approach (2). There is definitely consistency merit for approach (3), but it comes at a cost - there's more magic going on, which could be confusing in some circumstances. Paul --~--~-~--~~~---~--~~ 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 this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: sqlite PK autoincrement not working when you do a composite PK?
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 support/wrapping/hiding of ugly details by SA. This is often a difficulty for libraries that provide a portable layer over different implementations. GUI toolkits are a good example. The library essentially has three choices: 1) Only expose functionality that exists on all the implementations 2) Expose the user to the slight differences between implementations 3) Expose consistent functionality, and where an implementation lacks support, fake it In practice, (1) is usually a poor option as it's too restrictive. SQLAlchemy currently takes approach (2). There is definitely consistency merit for approach (3), but it comes at a cost - there's more magic going on, which could be confusing in some circumstances. i think there's something 2.5, allow user to make his own support/settings, let him take the decision - preferences-like; e.g. a widget with a set of general attributes and several sets of implementation-dependent extra attributes, switched depending on implementation - the user can setup them all. well maybe i got a mix of all them 3, for different aspects. e.g. if oracle db will disallow me to use my 50-long names, i'll mangle them somewhere in the middle, but will not allow such meaningless restriction to cripple all the model above. while for other things i just surrender and dont use the features... --~--~-~--~~~---~--~~ 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 this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Absurd operational error in SQLite
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 album_id FROM soup JOIN (album JOIN vinyl ON vinyl.id = album.id) ON vinyl.id = soup.id How would you interpret this? Help much appreciated. 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, ...), ...) just a little taste of my world ! :) --~--~-~--~~~---~--~~ 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 this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: sqlite PK autoincrement not working when you do a composite PK?
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 database implementations away... 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? 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. I wouldn't favor a built in system of guessing within the sqlite dialect how to autoincrement a composite PK field without explicit user intervention. The dialects don't intend to build a completely uniform layer over all database backends (for example, when using Oracle, you are required to set up a default generator, usually a Sequence, in all cases) - the idea of a dialect's default behavior is that it uses what the database backend provides by default and that's it. --~--~-~--~~~---~--~~ 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 this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: sqlite PK autoincrement not working when you do a composite PK?
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, including when aliases are created, etc. In compiler.py, all names go through the same length filter no matter how they got generated (the only exception to this is the too long index names ticket which is strictly a schema thing). We have a long labels test specifically for this, and lots of ORM tests generate very long names as well (all of which work fine with Oracle). We did a tremendous amount of development on this a few years back and noone has had issues since. can you post a ticket with an example ?Also if producing fixes, keep in mind theres some compiler differences between 0.4 and 0.5, 0.5 is the direction we're heading * missing support for the BOOL data type there may or may not be a ticket for this (please post one if not) * missing support for boolean expressions in the column list ( select([tbl.c.col1 == tbl.c.col2]) ) (related to the last one above) ditto --~--~-~--~~~---~--~~ 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 this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Temporary tables patch and postgresql's COPY
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()
http://www.sqlalchemy.org/trac/ticket/1075
I hope you'll accept the patch, considering that was how it was
discussed in the mailing list a month ago.
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, 'test_copy') will initiate a COPY using io (which
can be any python file-like object) to the table 'test_copy'
copy_to is similar and copy_expert allows you to form your own COPY
statement.
With postgresql, COPY is far faster than doing inserts.
Thanks,
Jonathan Hseu
--~--~-~--~~~---~--~~
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 this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: sqlite PK autoincrement not working when you do a composite PK?
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,
anon_1.people_company_id AS anon_1_people_company_id,
anon_1.people_name AS anon_1_people_name, anon_1.people_type AS
anon_1_people_type, anon_1.engineers_person_id AS
anon_1_engineers_person_id, anon_1.engineers_status AS
anon_1_engineers_status, anon_1.engineers_engineer_name AS
anon_1_engineers_engineer_name, anon_1.engineers_primary_language AS
anon_1_engineers_primary_language, anon_1.managers_person_id AS
anon_1_managers_person_id, anon_1.managers_status AS
anon_1_managers_status, anon_1.managers_manager_name AS
anon_1_managers_manager_name, anon_1.boss_boss_id AS
anon_1_boss_boss_id, anon_1.boss_golf_swing AS anon_1_boss_golf_swing,
machines_1.machine_id AS machines_1_machine_id, machines_1.name AS
machines_1_name, machines_1.engineer_id AS machines_1_engineer_id
FROM (SELECT people.person_id AS people_person_id, people.company_id
AS people_company_id, people.name AS people_name, people.type AS
people_type, engineers.person_id AS engineers_person_id,
engineers.status AS engineers_status, engineers.engineer_name AS
engineers_engineer_name, engineers.primary_language AS
engineers_primary_language, managers.person_id AS managers_person_id,
managers.status AS managers_status, managers.manager_name AS
managers_manager_name, boss.boss_id AS boss_boss_id, boss.golf_swing
AS boss_golf_swing
FROM people LEFT OUTER JOIN engineers ON people.person_id =
engineers.person_id LEFT OUTER JOIN managers ON people.person_id =
managers.person_id LEFT OUTER JOIN boss ON managers.person_id =
boss.boss_id ORDER BY people.person_id
LIMIT 2 OFFSET 1) AS anon_1 LEFT OUTER JOIN machines AS machines_1
ON anon_1.engineers_person_id = machines_1.engineer_id ORDER BY
anon_1.people_person_id, machines_1.oid
of note is the anonymous label anon_1_engineers_primary_language, 34
characters. This label is generated from an anonymous alias name
combined with a column name, which is itself a combination of the
original table name and column name. So theres three stages of name
generation represented here.
Here it is on oracle, including the result rows:
SELECT anon_1.people_person_id AS anon_1_people_person_id,
anon_1.people_company_id AS anon_1_people_company_id,
anon_1.people_name AS anon_1_people_name, anon_1.people_type AS
anon_1_people_type, anon_1.managers_person_id AS
anon_1_managers_person_id, anon_1.managers_status AS
anon_1_managers_status, anon_1.managers_manager_name AS
anon_1_managers_manager_name, anon_1.boss_boss_id AS
anon_1_boss_boss_id, anon_1.boss_golf_swing AS anon_1_boss_golf_swing,
anon_1.engineers_person_id AS anon_1_engineers_person_id,
anon_1.engineers_status AS anon_1_engineers_status,
anon_1.engineers_engineer_name AS anon_1_engineers_engineer_name,
anon_1.engineers_primary_language AS anon_1_engineers_primary_1,
machines_1.machine_id AS machines_1_machine_id, machines_1.name AS
machines_1_name, machines_1.engineer_id AS machines_1_engineer_id
FROM (SELECT people_person_id, people_company_id, people_name,
people_type, managers_person_id, managers_status,
managers_manager_name, boss_boss_id, boss_golf_swing,
engineers_person_id, engineers_status, engineers_engineer_name,
engineers_primary_language
FROM (SELECT people.person_id AS people_person_id, people.company_id
AS people_company_id, people.name AS people_name, people.type AS
people_type, managers.person_id AS managers_person_id, managers.status
AS managers_status, managers.manager_name AS managers_manager_name,
boss.boss_id AS boss_boss_id, boss.golf_swing AS boss_golf_swing,
engineers.person_id AS engineers_person_id, engineers.status AS
engineers_status, engineers.engineer_name AS engineers_engineer_name,
engineers.primary_language AS engineers_primary_language, ROW_NUMBER()
OVER (ORDER BY people.person_id) AS ora_rn
FROM people LEFT OUTER JOIN managers ON people.person_id =
managers.person_id LEFT OUTER JOIN boss ON managers.person_id =
boss.boss_id LEFT OUTER JOIN engineers ON people.person_id =
engineers.person_id)
WHERE ora_rn1 AND ora_rn=3) anon_1 LEFT OUTER JOIN machines
machines_1 ON anon_1.engineers_person_id = machines_1.engineer_id
ORDER BY anon_1.people_person_id, machines_1.machine_id
INFO:sqlalchemy.engine.base.Engine.0x..4c:{}
DEBUG:sqlalchemy.engine.base.Engine.0x..4c:Col
('ANON_1_PEOPLE_PERSON_ID', 'ANON_1_PEOPLE_COMPANY_ID',
'ANON_1_PEOPLE_NAME', 'ANON_1_PEOPLE_TYPE',
'ANON_1_MANAGERS_PERSON_ID', 'ANON_1_MANAGERS_STATUS',
'ANON_1_MANAGERS_MANAGER_NAME', 'ANON_1_BOSS_BOSS_ID',
'ANON_1_BOSS_GOLF_SWING', 'ANON_1_ENGINEERS_PERSON_ID',
'ANON_1_ENGINEERS_STATUS', 'ANON_1_ENGINEERS_ENGINEER_NAME',
'ANON_1_ENGINEERS_PRIMARY_1',
[sqlalchemy] Re: Temporary tables patch and postgresql's COPY
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, 'test_copy') will initiate a COPY using io (which can be any python file-like object) to the table 'test_copy' copy_to is similar and copy_expert allows you to form your own COPY statement. With postgresql, COPY is far faster than doing inserts. theres nothing preventing you from calling copy() from the cursor yourself . conn = engine.connect() cursor = conn.connection.cursor() # go nuts with cursor as far as a COPY SQL construct, these are welcome as patches (which include unit tests) to be added to the postgres dialect, i.e. from sqlalchemy.databases.postgres import copy_from engine.execute(copy_from(sometable, 'somestring')) --~--~-~--~~~---~--~~ 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 this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Absurd operational error in SQLite
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 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 this query: SELECT album.id AS album_id FROM soup JOIN (album JOIN vinyl ON vinyl.id = album.id) ON vinyl.id = soup.id --instead of-- SELECT album.id AS album_id FROM soup JOIN album on soup.id = album.id JOIN vinyl ON vinyl.id = soup.id That is, SQLA seems to make a left join (or whatever it is) by itself. How can tell it do this differently? just a little taste of my world ! :) :-) \malthe --~--~-~--~~~---~--~~ 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 this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Absurd operational error in SQLite
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 this query: SELECT album.id AS album_id FROM soup JOIN (album JOIN vinyl ON vinyl.id = album.id) ON vinyl.id = soup.id --instead of-- SELECT album.id AS album_id FROM soup JOIN album on soup.id = album.id JOIN vinyl ON vinyl.id = soup.id That is, SQLA seems to make a left join (or whatever it is) by itself. How can tell it do this differently? oh. how are you getting it to join from soup- (album join vinyl) ? soup has a relation to album join vinyl and you're using query.join() ? it should be creating an aliased subquery for the right side of the join in that case. I thought 0.4 was able to do this; 0.5 definitely can. --~--~-~--~~~---~--~~ 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 this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: sqlite PK autoincrement not working when you do a composite PK?
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 make ColumnDefault dialect dependent. I wouldn't favor a built in system of guessing within the sqlite dialect how to autoincrement a composite PK field without explicit user intervention. Why not? Is it really guessing when the table has been defined precisely within SQLA? If you have a Column that has been defined to be an Integer primary key that is supposed to autoincrement, and you are using sqlite... how could you be wrong? The worst case I can think of is if sqlite changes in the future to actually support it, in which case you'd either change the dialect or get an error. No? The dialects don't intend to build a completely uniform layer over all database backends (for example, when using Oracle, you are required to set up a default generator, usually a Sequence, in all cases) - the idea of a dialect's default behavior is that it uses what the database backend provides by default and that's it. But at the same time the dialect is also abstracting out many of the annoying backend type differences. I thought that a big part of SQLA was going to be allowing the use of any back end. Maybe I'll have to re-evaluate my approach... more likely I'll just keep plugging away and see what obstacles I hit! --~--~-~--~~~---~--~~ 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 this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: sqlite PK autoincrement not working when you do a composite PK?
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( that method); replace some lines in that with yours; compile; replace the method with the new version. this works if u have sources; if its just *.pyc, sorry. All good ways. I was planning on b), but I just couldn't (can't) locate the right replacement location underneath the SQLA classes I'm using (Session, Engine, Metadata, etc). Where the heck is the Compiler? --~--~-~--~~~---~--~~ 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 this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
