Jim, Try this : bigint_id=False in connection string I think...
https://groups.google.com/forum/?fromgroups#!topic/web2py-developers/DrCFEnZIYt4 Also, I think with trunk your entire database models is now consider bigint. It maybe not what you want. Richard On Tue, May 8, 2012 at 10:53 AM, Jim S <j...@qlf.com> wrote: > I upgraded to this trunk right when it came out. I upgrade trunk again > yesterday (5/7/2012) and created a new table today with a reference field > to an old table. Here is the SQL that was generated (MySQL). > CREATE TABLE ticketActivity( > ticketActivityId INT AUTO_INCREMENT NOT NULL, > ticketId INT, INDEX ticketId__idx (ticketId), FOREIGN KEY (ticketId) > REFERENCES ticket(ticketId) ON DELETE CASCADE, > createdOn DATETIME, > activity LONGTEXT, > PRIMARY KEY(ticketActivityId) > ) ENGINE=InnoDB CHARACTER SET utf8; > > This failed. I changed the INTs to BIGINTs and it worked. I'm wondering > if something related to this post got reverted that caused my generated SQL > to not use BIGINT now. > > Or, am I losing my mind? --> > https://groups.google.com/forum/?fromgroups#!topic/web2py/nGB1nYlpHwA > > -Jim > > On Saturday, April 21, 2012 12:37:15 PM UTC-5, Massimo Di Pierro wrote: >> >> There is a change in trunk. I replaced 'id' and 'reference' types from >> INT to BIGINT (when supported). >> If you have an existing table it should not cause a migration and there >> is an explicit check to avoid a migration that would break tables. >> The bottom line is hat new tables are not affected but new tables will >> have the BIGINT. >> >> SQLite does not support BIGINT AUTOINCREMENT therefore nothing happens >> there. >> >> Yet, this needs to be tested with the other DB engines. Make sure you >> backup your data before testing this feature by upgrading to trunk your >> production environment. >> >> massimo >> >> > > On Saturday, April 21, 2012 12:37:15 PM UTC-5, Massimo Di Pierro wrote: >> >> There is a change in trunk. I replaced 'id' and 'reference' types from >> INT to BIGINT (when supported). >> If you have an existing table it should not cause a migration and there >> is an explicit check to avoid a migration that would break tables. >> The bottom line is hat new tables are not affected but new tables will >> have the BIGINT. >> >> SQLite does not support BIGINT AUTOINCREMENT therefore nothing happens >> there. >> >> Yet, this needs to be tested with the other DB engines. Make sure you >> backup your data before testing this feature by upgrading to trunk your >> production environment. >> >> massimo >> >> > > On Saturday, April 21, 2012 12:37:15 PM UTC-5, Massimo Di Pierro wrote: >> >> There is a change in trunk. I replaced 'id' and 'reference' types from >> INT to BIGINT (when supported). >> If you have an existing table it should not cause a migration and there >> is an explicit check to avoid a migration that would break tables. >> The bottom line is hat new tables are not affected but new tables will >> have the BIGINT. >> >> SQLite does not support BIGINT AUTOINCREMENT therefore nothing happens >> there. >> >> Yet, this needs to be tested with the other DB engines. Make sure you >> backup your data before testing this feature by upgrading to trunk your >> production environment. >> >> massimo >> >> > > On Saturday, April 21, 2012 12:37:15 PM UTC-5, Massimo Di Pierro wrote: >> >> There is a change in trunk. I replaced 'id' and 'reference' types from >> INT to BIGINT (when supported). >> If you have an existing table it should not cause a migration and there >> is an explicit check to avoid a migration that would break tables. >> The bottom line is hat new tables are not affected but new tables will >> have the BIGINT. >> >> SQLite does not support BIGINT AUTOINCREMENT therefore nothing happens >> there. >> >> Yet, this needs to be tested with the other DB engines. Make sure you >> backup your data before testing this feature by upgrading to trunk your >> production environment. >> >> massimo >> >> > > On Saturday, April 21, 2012 12:37:15 PM UTC-5, Massimo Di Pierro wrote: >> >> There is a change in trunk. I replaced 'id' and 'reference' types from >> INT to BIGINT (when supported). >> If you have an existing table it should not cause a migration and there >> is an explicit check to avoid a migration that would break tables. >> The bottom line is hat new tables are not affected but new tables will >> have the BIGINT. >> >> SQLite does not support BIGINT AUTOINCREMENT therefore nothing happens >> there. >> >> Yet, this needs to be tested with the other DB engines. Make sure you >> backup your data before testing this feature by upgrading to trunk your >> production environment. >> >> massimo >> >> >
