On 28 Aug 2012, at 10:17 AM, Chris <ch...@spitfireinnovation.com> wrote:
> 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?
>
What I've been doing is defining migrate as a string, which becomes the
name.table prefix instead of the hash. You can go ahead and build the string
out of whatever you care to.
--
