I have been having a very busy weekend trying to do a very simple and trivial task for every data base - a Restore.
Restore in the current state of the trunk is broken but this is not that major problem - we know it will be fixed soon or later.
The major problem is the concept of changing the admin password with every single restore operation.
In my case because of the way restore breaks, the password becomes in a limbo state and it renders the whole db useless.
There must be some legacy reasons to choose the current design for the restore. Now when we have bigger and bigger databases and it is more often to have cases when we need to do a partial restore: it could be a data subset we are working on or a client specific data collection. And to change the admin password for every (even partial) restore is errrr unexpected side effect.
I can not even imagine what would have been the consequences if this was a case in a production. Probably catastrophic.
I know the first response will be to remind me that I should not relay on the code from the trunk to be perfectly stable. You are right, but this is not the point. My point is: this is an implementation that holds a potential for locking out the database if a restore operation goes badly for some reason - expected or unexpected (remember Murphy's law - if something can go wrong it always will :-).
As my experience showed the current implementation of Restore operation is potentially dangerous for the integrity of the whole database (even if we do a partial restore), which ironically is against the nature of Restore operation on the first place.
I would like to propose to change Restore operation to do what it is supposed to do - restore data only and remove the side effect of changing the admin password which is undesirable, dangerous ( and to me personally it just does not make any sense).
Please comment. This is important.