Hi Jim, The default now is bigint_id=False, so try to pass bigint_id=True in the connection string.
Carlos On Tuesday, May 8, 2012 11:40:44 AM UTC-5, Jim S wrote: > > My problem is the opposite. All of my tables now have BIGINT for the id > columns. The SQL generated today is now creating them with INT columns and > the reference fields are also being created with INT. When I changed the > SQL (using an outside SQL tool) from using INTs to BIGINTs it all worked > (with migrate=False, fake_migrate=True). > > I'm not passing anything to bigint_id in the connect string. I do want > (and have) all my models using BIGINT now. Except for this new problem, > all has been fine. > > -Jim > > On 5/8/2012 10:27 AM, Richard Vézina wrote: > > 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 >>> >>> >> >
