[sqlalchemy] Re: Using TurboGears/SQLAlchemy with SQL Server, via adodbapi
hi Paul - If you want to make a patch for these changes, that would be great. Im looking at mssql.py and it seems to have a lot of twiddly details for both pymssql and ado (I didnt write the mssql.py module), so I can't readily say what the proper solutions should be. Rick Morrison is the maintainer of the mssql.py module, so if you can illustrate the specific lines for your changes we can get Rick's input on them. - mike --~--~-~--~~~---~--~~ 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] Order of constraints at creation time
[This is a repost, direct mail wasn't working] Hi all, I spent a moment at fixing here and there to make some test work under firebird. I'm out of luck figuring out the proper solution for engine.ReflectionTest.testbasic: FB2 fails here because the test tries to create a table with a primary key and a foreign key to itself, but the issued SQL define the foreign key sooner than that the primary key. In other words, the statement is something like CREATE TABLE engine_users ( user_id INTEGER, ... FOREIGN KEY (parent_user_id) REFERENCES engine_users (user_id) PRIMARY KEY (user_id) ) This works for example in sqlite, but AFAICS FB2 is not smart enough: it accepts the stmt only if I swap the constraints, otherwise it complains about a missing unique index on the target field... Digging the issue, I was looking at AnsiSchemaGenerator.visit_table() which, at some point, calls .get_column_specification() passing a first_pk flag, which at first seemed what I was looking for: as the comment suggests, if at all possible the primary key should go earlier on the column itself, but: a) none of the current backends make any use of it b) even if they did, how could they omit the primary key constraint from the final loop on the table's ones? Ideally the PK constraint (if any) should be visited before the remaining FK constraints, but I don't see any sensible way of doing that, since the container is a set. Any advice? Thanks in advance, and happy gnu year everybody ;) ciao, lele. --~--~-~--~~~---~--~~ 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] Order of constraints at creation time
Hi all, I spent a moment at fixing here and there to make some test work under firebird. I'm out of luck figuring out the proper solution for engine.ReflectionTest.testbasic: FB2 fails here because the test tries to create a table with a primary key and a foreign key to itself, but the issued SQL define the foreign key sooner than that the primary key. In other words, the statement is something like CREATE TABLE engine_users ( user_id INTEGER, ... FOREIGN KEY (parent_user_id) REFERENCES engine_users (user_id) PRIMARY KEY (user_id) ) This works for example in sqlite, but AFAICS FB2 is not smart enough: it accepts the stmt only if I swap the constraints, otherwise it complains about a missing unique index on the target field... Digging the issue, I was looking at AnsiSchemaGenerator.visit_table() which, at some point, calls .get_column_specification() passing a first_pk flag, which at first seemed what I was looking for: as the comment suggests, if at all possible the primary key should go earlier on the column itself, but: a) none of the current backends make any use of it b) even if they did, how could they omit the primary key constraint from the final loop on the table's ones? Ideally the PK constraint (if any) should be visited before the remaining FK constraints, but I don't see any sensible way of doing that, since the container is a set. Any advice? Thanks in advance, and happy gnu year everybody ;) ciao, lele. --~--~-~--~~~---~--~~ 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] Order of constraints at creation time
Hi all, I spent a moment at fixing here and there to make some test work under firebird. I'm out of luck figuring out the proper solution for engine.ReflectionTest.testbasic: FB2 fails here because the test tries to create a table with a primary key and a foreign key to itself, but the issued SQL define the foreign key sooner than that the primary key. In other words, the statement is something like CREATE TABLE engine_users ( user_id INTEGER, ... FOREIGN KEY (parent_user_id) REFERENCES engine_users (user_id) PRIMARY KEY (user_id) ) This works for example in sqlite, but AFAICS FB2 is not smart enough: it accepts the stmt only if I swap the constraints, otherwise it complains about a missing unique index on the target field... Digging the issue, I was looking at AnsiSchemaGenerator.visit_table() which, at some point, calls .get_column_specification() passing a first_pk flag, which at first seemed what I was looking for: as the comment suggests, if at all possible the primary key should go earlier on the column itself, but: a) none of the current backends make any use of it b) even if they did, how could they omit the primary key constraint from the final loop on the table's ones? Ideally the PK constraint (if any) should be visited before the remaining FK constraints, but I don't see any sensible way of doing that, since the container is a set. Any advice? Thanks in advance, and happy gnu year everybody ;) ciao, lele. --~--~-~--~~~---~--~~ 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] constants in strings
Hi! Just for curiosity: why sqlalchemy is using constants in strings? E.g.: cascade = all, delete-orphan Why not something like: cascade = ALL | DELETE_ORPHAN I'm asking because I realized that when I make a mistake in the string the sqlalchemy doesn't report anything and my program crashes later and I never see the connection to the typing error. Another thing is that putting constants/directives in a string separated by a comma is not very clean in this case. David --~--~-~--~~~---~--~~ 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] Mailman trunk now backed by SQLAlchemy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I thought I would let you know that I've committed a bunch of changes to the Mailman svn trunk that integrates a SQLAlchemy storage for all mailing list data. My goal was to be able to make this change without disrupting the basic architecture and current code base, and I think I've largely accomplished that. Our trunk is far from ready for prime time, but I've been very happy with how easy SQLAlchemy is to use so far. Right now I still use a bunch of PickleType columns for non-basic data types (e.g. attributes which contain lists, dicts, instances, etc.). I plan on incrementally moving each of those to their own separate tables. Having the pickle columns has really eased the transition though. Good stuff! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRZbuTnEjvBPtnXfVAQIOzQP+ItkfrRhO50FEtv+OKSB1IGILpqKgDtcU Rbdod3Qv3b+hAAKtf32JSperDAltxj1fy6yoqKE8Uxkq5UIWVNTgtkye1GXIINM8 s32aqdOGmDS5LAGZtCUMakNaY33QnoQKSPZ6A+2hHrd4ZCGCQf2F10SdLqnzSY8J scG+aggm6GY= =5mUv -END PGP SIGNATURE- --~--~-~--~~~---~--~~ 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: Mailman trunk now backed by SQLAlchemy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 1, 2007, at 3:24 PM, Michael Bayer wrote: I may put a note on the SQLAlchemy site about this, its big news ! Please feel free Mike, and thanks! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRZlwgHEjvBPtnXfVAQJ8mAQAuhT29tlRdi+7pZxasWn/aSfUe29SS4s1 B+qvOtI/mV2smsu5yIsS1BX+zNi3xJn3jeK963I6joHKM2d3CzK5+V+zAFzO7Sr4 JNdrdBy5liVcay/E9C+hBCdEFzygPR+7TPAOxCDmVNjh+KEcFYiohf3fthisRY9N WDkyKaBEG+c= =GTnV -END PGP SIGNATURE- --~--~-~--~~~---~--~~ 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: constants in strings
for simplicity and also it was emulating that of hibernate. better solution here would be for invalid options inside the cascade string to raise an error. ive added ticket #406 for this. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
