Michael, Thanks for your reply. Not sure I totally understand what you mean by 'resolve conflicts by hand'. If we hack about with the Insoshi code and need to create a new table (for instance) so that we can add some additional functionality for our own site does this mean we have to manually renumber all our migrations and rerun them if you do add a migration? For instance I might be using Insoshi to build a game, and want to create tables for the number of virtual swords a user has.
One possible hack for this would be to create ten (or more) 'dummy' migrations. In insoshi these would be blank migrations which don't do anything but increase the migration version number. Currently we are on migration 25. If blank migrations were added up to (say) 40 then we could use migrations 25-40 to make our own edits to the database, and when new insoshi migrations come out they start at #40 upwards. It's not a very elegant solution, but it would prevent a conflict and having to rename migrations by hand each time an update is pushed - and it wouldn't take very long to setup. Also this way we don't lose data contained in the fields. At the moment we would need to roll back the migration version number to 25 if you push out a new migration, which would lose all the data in a live site. Antony --~--~---------~--~----~------------~-------~--~----~ Insoshi developer site: http://dogfood.insoshi.com/ Insoshi documentation: http://docs.insoshi.com/ You received this message because you are subscribed to the Google Groups "Insoshi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/insoshi?hl=en -~----------~----~----~----~------~----~------~--~---
