Missing migration file

[Ben Edwards]

I accidentally deleted a migration file and its up.  I looked in the development.log and it was to create  a view I don’t actually need.

database: eventpuddle_development

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     20170901234251  Create venues
   up     20170902001958  Create ref values
   up     20170902005356  Create events
   up     20170902010547  Create logs
   up     20170902125827  Fix column name
   up     20170902184156  Add events fk
   up     20170902190440  Add null constraints
   up     20170903000942  ********** NO FILE **********
   up     20170903012041  Upcomming events
   up     20170904191027  Devise create users
   up     20170904215057  Add roles to users

So what should I do?

[Walter Lee Davis]

Have you run these migrations in production yet, or is it just in development? Because you can back your way out of this manually, but if you aren't careful, you can end up with things out of synch between your code and your actual database. The migrations and the schema_migrations table are a kind of "git" for your database. Speaking of which, can't you recover the missing migration file from a previous git commit or branch?

Assuming you cannot, and you are willing to live on the edge (which would be a pretty redundant statement if you were not running git, you will admit):

Manually delete (through SQL) the view that this migration would have created, if it exists, in all databases.
Manually delete (through SQL) the row with the value '20170903000942' from the schema_migrations table.

Now it is as though that missing migration was never run and doesn't exist.

Walter

> --
> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
> To post to this group, send email to rubyonra...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/d438d78f-4484-49ec-83f6-6933d2dfaad4%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Ben Edwards]

PS I haven’t actually deployed anything to production.  I do want to this week which is why I want to sort this out.

[Hassan Schroeder]

On Tue, Sep 5, 2017 at 5:16 PM, Walter Lee Davis <wa...@wdstudio.com> wrote:

> ... and you are willing to live on the edge (which would be a pretty redundant statement if you were not running git, you will admit):

LOL

--
Hassan Schroeder ------------------------ hassan.s...@gmail.com
twitter: @hassan
Consulting Availability : Silicon Valley or remote

[Ben Edwards]

Not sure why you thought I was not  using git.  Do you say deleting the view from the DB and the schema_migrations table is risky as you you think rails may hold the data about the migration somewhere else? 

On the git front I don’t tend to commit stuff that does not work but I guess if I create a local branch for stuff and don’t commit it remotely I can delete the branch and keep my remote git pure(ish) but the rails database would still be unconsistent, or should I use a efferent git workflow.

[Ben Edwards]

PS changes are not in production.

[Hassan Schroeder]

On Wed, Sep 6, 2017 at 1:07 AM, Ben Edwards <lo...@funkytwig.com> wrote:

> On the git front I don’t tend to commit stuff that does not work but I guess
> if I create a local branch for stuff and don’t commit it remotely I can
> delete the branch and keep my remote git pure(ish) but the rails database
> would still be unconsistent, or should I use a efferent git workflow.

"pure"? In general you'll be best off always working in a feature
branch and making frequent commits, especially for things like
migrations that have side effects.

And you can delete remote branches as well as local ones, so...

[Ben Edwards]

By pure I mean don’t have code in a remote repository that does not work, but if I keep it in a local one is is not an issue   Surrey if I run a migration and then delete the branch the migrations table will be out of sync.  I guess the answer is to be more careful:).  I guess backing up the DB first is another strategy.

[fugee ohu]

Migrations create views? I didn't know that

[Hassan Schroeder]

On Fri, Sep 22, 2017 at 7:15 AM, fugee ohu <fuge...@gmail.com> wrote:

>> Manually delete (through SQL) the view that this migration would have
>> created, if it exists, in all databases.

> Migrations create views? I didn't know that

As the context indicates, the "view" refers to the database, e.g.

https://dev.mysql.com/doc/refman/5.7/en/create-view.html

[Ben Edwards]

The are suposed to but probably best to use the scinic gem.  I had creating views without it working but when I tried to deplay alough migration did not error I had to add it manualy.