Well, that explains things quite nicely. I guess that is what I get for
working with trunk all the time.
This also explains what was happening to me the post I referenced below.
-Jim
On 5/8/2012 11:48 AM, Carlos wrote:
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
<https://groups.google.com/forum/?fromgroups#%21topic/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
<mailto: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
<https://groups.google.com/forum/?fromgroups#%21topic/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
