Question

I’ve got a rails application where users have to log in. Therefore in order for the application to be usable, there must be one initial user in the system for the first person to log in with (they can then create subsequent users). Up to now I’ve used a migration to add a special user to the database.

After asking this question, it seems that I should be using db:schema:load, rather than running the migrations, to set up fresh databases on new development machines. Unfortunately, this doesn’t seem to include the migrations which insert data, only those which set up tables, keys etc.

My question is, what’s the best way to handle this situation:

1. Is there a way to get d:s:l to include data-insertion migrations?
2. Should I not be using migrations at all to insert data this way?
3. Should I not be pre-populating the database with data at all? Should I update the application code so that it handles the case where there are no users gracefully, and lets an initial user account be created live from within the application?
4. Any other options? 🙂

Answer 1

I thought I’d summarise some of the great answers I’ve had to this question, together with my own thoughts now I’ve read them all 🙂

There are two distinct issues here:

1. Should I pre-populate the database with my special ‘admin’ user? Or should the application provide a way to set up when it’s first used?
2. How does one pre-populate the database with data? Note that this is a valid question regardless of the answer to part 1: there are other usage scenarios for pre-population than an admin user.

For (1), it seems that setting up the first user from within the application itself is quite a bit of extra work, for functionality which is, by definition, hardly ever used. It may be slightly more secure, however, as it forces the user to set a password of their choice. The best solution is in between these two extremes: have a script (or rake task, or whatever) to set up the initial user. The script can then be set up to auto-populate with a default password during development, and to require a password to be entered during production installation/deployment (if you want to discourage a default password for the administrator).

For (2), it appears that there are a number of good, valid solutions. A rake task seems a good way, and there are some plugins to make this even easier. Just look through some of the other answers to see the details of those 🙂