Darryl L. Pierce wrote:> Signed-off-by: Darryl L. Pierce <dpierce at redhat.com>
> ---
> .../009_rename_user_to_uid_in_permissions.rb | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
> create mode 100644
wui/src/db/migrate/009_rename_user_to_uid_in_permissions.rb
>
> diff --git a/wui/src/db/migrate/009_rename_user_to_uid_in_permissions.rb
b/wui/src/db/migrate/009_rename_user_to_uid_in_permissions.rb
> new file mode 100644
> index 0000000..fe59baf
> --- /dev/null
> +++ b/wui/src/db/migrate/009_rename_user_to_uid_in_permissions.rb
> @@ -0,0 +1,9 @@
> +class RenameUserToUidInPermissions < ActiveRecord::Migration
> + def self.up
> + rename_column :permissions, :user, :uid
> + end
> +
> + def self.down
> + rename_column :permissions, :uid, :user
> + end
> +end
>
For migrations, we should probably clarify how we want to handle them
going forward. For initial development, we haven't been tracking every
db change as a separate migration, since things were so in flux, and we
weren't supporting data upgrades across versions anyway -- we've been
essentially maintaining our current set of migrates as a working schema.
On the other hand, official rails recommendations are to do as in this
patch -- never change a migration once it's committed.
Long term, once we've got to support upgrades, that's the way we've
got
to go. The question is when do we switch over to that model. Is now as
good a time as any, or do we keep editing the migrations until we've at
least reached a stable functional demo?
Any thoughts?
Scott