Background: web2py keeps track of database definitions using files in each
app's ./databases directory. The basic concept is, for each table
definition a pickle file is created storing attributes defined in web2py /
not necessarily defined in the database; and the name of each pickle file
incorporates a hash based on the database URI + the table name, so one app
can access multiple databases and not experience name collisions if tables
with the same name occur in more than one database. Seems like a good
approach overall.
The only problem I've had with this approach is, the hash is based on the
full URI, and therefore it changes when the user name and/or password for a
database connection changes. If you change a password, then you have to
change the URI, and the "same" database will have a different hash, and the
next time you run the app, web2py won't be able to identify the .table
files for that DB, and you end up with a bunch of "Table already exists"
errors and possibly a failed migration to clean up. Changing passwords
regularly is good practice, and in my case where we move code amon servers
as a project moves from dev --> test --> stage --> prod, this changes
fairly often.
Here's my solution to the problem:
0. know that the hash is computed as hashlib.md5('uri string').hexdigest()
1. get the old URI, run it through MD5 --> oldhash
2. get the new URI, run it though MD5 --> newhash
3. now assuming you are running bash ...
4. cd /to/the/databases/folder
5. for i in oldhash*.table; do j=`echo $i | sed 's/oldhash/newhash/g'`; cp
"$i" "$j"; done
In other words, copy all existing .table files the name of which used the
old hash, to use the new hash.
Two questions:
(1) Do you have a better way to deal with this?
(2) I wonder if a change to the current behavior would be better -- change
the logic to build a hash using all of the URI except the password part?
Changing server or DB name feels like a real change to me; and in general
changing just the user ID is too since the user may have different
permissions, views etc. in the same database. But changing just the
password? Should not change the underlying identity of the database
connection or database object definitions. (In my view of the world.)
What do you think?
Cheers
-- Chris
--
