[CRITIQUE REQUEST] Migration Practices

[eluser]Lewis Cowles[/eluser]
I have read the docs for both, thanks. I hope you can see how my code is similar to that in the docs, but saves me rewriting for every new table by looping through a variable, this should possibly be a const, but for now it works as-is.

I have since made the code shorter to type, by defining some class constants, to fill in the arrays for types like the id field and some fixed length fields including the date and time-stamp fields I intend on using.

The main reason for my question is that I tend to write very data-centric apps with lots of inter-connected relational tables. For now, rather than try to make CI guess if the table is ISAM or INNO, I have been soft-relating tables. Also the system I am developing has to connect to an MSSQL DB & a MYSQL DB... But thats another story.

I did try separating the code into different files, one for each table. Unfortunately I get an error when having one file per db_model per revision.

I also considered writing the code into each model that extends my base class for using the database from a model (aptly named DB_Model), but it seemed to me to be superfluous to the model and a violation of the separation of concerns.

I was just wondering if anyone else has a "neater" more "correct" way to do this.

On a separate note, has anyone else noticed that if there is a problem with migrating the db the migration table is still set up, which is a pain as it means that I have to manually remove it. I suppose I could just use the dbforge library, without the migration library,

After thinking long and hard, I concluded using migrations for this type of tasks is the "CodeIgniter" way to do these things, especially as writing the raw SQL would take more planning and this seems to fit into my AGILE work-flow.

I have looked into the Migration class and can only assume that