I’m working on a module for which I’d like to have a couple extra tables in the database. I’d also like to use ORM for the model of my module.
Because the Application.cfc for ContentBox has ormsettings.dbupdate=“none”, the app will bomb the next time ORM is reloaded since any persistent entities contained in my module will not yet have associated tables created. Obviously, the App.cfc could be updated by the developer before installation, or the tables could be manually created by the developer, but that pretty much defeats the purpose of a pluggable module.
So then, my question is really what the best approach to take here is. Is there a way to make this work with ORM (perhaps a post-installation hook to create the tables via sql), or do I need to take another approach with the model?
This is a hard decision. I chose to disable the dbupdate as many organizations are not very keen on modifications of the production database. Thus, it would be either a manual installation or via SQL. The auto-update features requires the use of SQL for modification and not relying on the ORM and advised as so.
I would say use SQL to modify the DB or modify the Application.cfc but warn the users.
First, thanks for pointing me to your blog post–nice write up on that!
I was originally planning on just using the settings as you outlined (including the serialization of my settings structure), but the way I was implementing it was starting to feel really dirty–I had multiple records in the settings table, each storing individual configuration data for each record, and none of them “settings”-ish…clearly beyond the scope of what that table is intended for
So, I’m going to keep plugging away to try to find a good way of publishing this module in a somewhat easy way to install.
