Question

I really love the concept of RedBeanPHP. Under development one doesn’t have to worry about using the database, RedBean does it all for you. The tables form themselves while you work, and when you’re happy with the tables you freeze them. The only issue I see with this is when you move the project to a new system. One of the great parts of an ORM is that the database table is created from the PHP Model, meaning that you don’t have to constantly do exports of the database structure to keep it safe. I don’t see how this would be accomplished using RedBean, since it forms the table structure after repeated usage over time with variable data.

I realize that defining the structure of the table beforehand would kinda weaken the point of using RedBean in the first place, but I would at least like to define the structure of the database in PHP after using RedBean in “dynamic mode” during development, so that moving the project between systems wouldn’t be as painful.

I hope I made my concerns clear enough to be adressed by somebody who has worked with RedBeanPHP and perhaps faced this issue before.

Thanks

Answer 1

I haven’t executed it yet but my idea is to make a migration script that uses FUSE to load all bean types, and iterates creating one bean with fake data for each bean type (based on the bean’s metadata information) and storing it. This will recreate the table structure based on models, then the script would truncate the tables and import the production data into it.

Not very elegant since you would need to declare the database structure somewhere in your models, but it’s impossible to achieve that with zero configuration.