Opened 16 years ago
Closed 12 years ago
#4560 closed defect (wontfix)
Unsupported operand type(s) for +: 'NoneType' and 'int'
Reported by: | Matt Callaghan | Owned by: | John Hampton |
---|---|---|---|
Priority: | normal | Component: | SqliteToPgScript |
Severity: | blocker | Keywords: | |
Cc: | John Hampton | Trac Release: | 0.11 |
Description
Hi,
I'm trying to upgrade my SQLITE db to POSTGRES. I run the following:
./sqlite2pg -e /srv/trac -p 'postgres://postgres:mypassword@localhost/trac?schema=myschema'
And receive the following error:
Traceback (most recent call last): File "./sqlite2pg", line 335, in <module> sys.exit(main(sys.argv[1:])) File "./sqlite2pg", line 331, in main Main(opts) File "./sqlite2pg", line 244, in Main pgenv = getPostgreSQLEnvironment(opts) File "./sqlite2pg", line 222, in getPostgreSQLEnvironment env.upgrade() File "/usr/lib/python2.5/site-packages/Trac-0.11.2.1-py2.5.egg/trac/env.py", line 449, in upgrade participant.upgrade_environment(db) File "/usr/lib/python2.5/site-packages/Trac-0.11.2.1-py2.5.egg/trac/env.py", line 502, in upgrade_environment for i in range(dbver + 1, db_default.db_version + 1): TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'
Attachments (0)
Change History (5)
comment:1 Changed 16 years ago by
comment:2 Changed 16 years ago by
I'm having exacly the same problem here Trac 0.11.1 from Debian repos (Lenny)
comment:3 Changed 16 years ago by
fyi, I'm having exactly the same problem when I try specify a different schema name. If I leave out the schema part, it works without a problem (Debian/Lenny).
comment:4 Changed 16 years ago by
I'm not sure if it really matters whether the trac tables are in schema 'tracschema' (or 'myschema', or whatever), or if they're in the public schema.
But, if you're using PostgreSQL 8+ and you want to have the tables in the correct schema, you can use sqlite2pg to migrate from sqlite into the postgres public schema and _then_ move it to your schema of choice.
1) run the conversion into the public schema
./sqlite2pg -e /srv/trac -p 'postgres://postgres:mypassword@localhost/trac'
2) create the schema
mach=> create schema myschema; CREATE SCHEMA
3) move all tables, one by one, into the new schema:
mach=>alter table table_one set schema myschema;
and repeat for all tables, indexes, and sequences
The Postgres 8 Docs can tell you more.
comment:5 Changed 12 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
This plugin is deprecated. See the TracMigratePlugin.
Any ideas on this problem? It might not even be a bug ... but I'm not sure what exactly is the issue. Seems to perhaps be related to trac itself?...