Ruby on Rails Monday, April 10, 2017

> On 2017-Apr-8, at 13:45 , Walter Lee Davis <waltd@wdstudio.com> wrote:
>
>
>> On Apr 7, 2017, at 11:03 PM, fugee ohu <fugee279@gmail.com> wrote:
>>
>> Also, of course I need the id's from the dumpfile to be inserted as the same values otherwise all relations would be borked

fugee,

This statement reveals the problem with your thinking on this.

AUTO_INCREMENT only takes place when the `id` is *not given* in the data.

ActiveRecord does not normally assign a value to the `id` and simply reflects the value assigned by the underlying database upon being saved. (I.e., INSERTed)

In Rails, the migrations are fundamentally *database* migrations, not _data_ migrations. (Though you can add or manipulate data within a migration, that is certainly *not* their primary purpose.)

As Walter points out, the db/seeds.rb file can be used to populate data, but that is typically minimal to get the system bootstrapped. Loading data from some other source is probably best approached as a stand-alone script that can be run once.

-Rob

>
> You seem to be going at this all sideways. When you stand up a server, you run the migrations on that server in the production environment. That connects to the production server, creates the database (which means it will have entirely no content in the tables, thus no need to artificially alter the auto-increment start point) and builds all the tables from scratch.
>
> Drop your database. Run the migrations on the server in the production environment. Please. You are hurting yourself, and it's difficult to watch.
>
> Adding data to the database (in order to mirror an existing data set elsewhere, or to set up some base accounts or relationships) is the job of the seeds.rb file. You run that separately, after you have created the database and all its tables, and you can put whatever IDs or relationships in there that you need.
>
> Editing the schema.rb file is a mistake, plain and simple. Think of this file as a log, showing all of the migrations run to date in a single place. Yes, you will find some examples out there where people use it to stand up their db server "in a hurry". But look at all the time you have spent trying to force-fit it into a purpose that it really should not serve! Run the migrations. That's what they are for. Use seeds to populate data if you need to. Don't cross the streams. Migrations are designed to be idempotent. Run them once, or many times, and you will get the same result. The schema is just a record of the current state, not a tool to be used to duplicate that database. And editing it should set off all sorts of warning bells, because the very next migration you create in your project will entirely erase that file and re-create it from scratch, deleting all of your changes.
>
> 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-talk+unsubscribe@googlegroups.com.
> To post to this group, send email to rubyonrails-talk@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/9BF2CA04-E424-4D73-BA71-64E52BDA1B0A%40wdstudio.com.
> For more options, visit https://groups.google.com/d/optout.

--
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-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/4F536876-AC7C-4A46-BE83-AA22E5745F3C%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment