That gave me plenty of information to reconstruct a framework for the database. But then I spent a couple of days exercising various paths through the code to flush out all of the errors. When one would surface, I'd track it down to what was missing in my schema, run my alter commands, update my build_schema.sql script and test some more.
Eventually after enough of this, my code started running w/o errors and I used a db dump to take a snapshot of the data schema, compared it to what I had developed as I went and resolved the differences. That then got stashed with the code so I didn't have to go through that again. The tricky part was restoring the indices. That took the sort of consideration that would have gone it to the initial development. And there were no error messages telling me I had fed in the wrong number of bind variables or inserted data into a column that didn't exist. Responding to errors is pretty straightforward. But the absence of errors is not proof that the code works as intended. So a thorough code review at the end would seem to be in order, preferably by someone not involved in reconstructing the package.
-- Hugh
In reply to Re: Parse PHP or Perl and Reconstruct MySQL Schema
by hesco
in thread Parse PHP or Perl and Reconstruct MySQL Schema
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |