In a project, the seeds.rb is getting complicated. We have a seeds/ directory with yml files containing data to be loaded. It should work on re-runs and it should not duplicate records (this is allowed in model). Well, the seeds.rb should be tested, it is used to update production. I'm not getting my head around this one though, wondering wether or not to move the logic to lib/ and write specs as normal. What would you do?
rails 3 with rspec.
I think you should try out the seed-fu gem:
https://github.com/mbleigh/seed-fu
It doesn't generate duplicate records and can help maintain the consistency of the data.
Related
I am using yaml files to provide initialisation data for the database and also to provide initialisation data for some of my services models. Where should I store these files in a ruby on rails app?
Based on ruby_newbie's comment and the general lack of other responses, it seems that there is no well defined rails way for this. Reasonable locations are
rails_root/data
rails_root/config/data
rails_root/db/data
You should put any data required for your application to run in the seeds file(db/seeds.rb). http://edgeguides.rubyonrails.org/active_record_migrations.html#migrations-and-seed-data
If you need create a initial database state you can use seeds files in "db/seeds/". After you can use rake to run and create initial state in your database.
In seeds file you can use Rails model without problems and run a follow command rake to create entries.
take db:seed
You can check Rails Documentation:
http://edgeguides.rubyonrails.org/active_record_migrations.html#migrations-and-seed-data
There may be good use case for loading fixed data into a constant without needing to store in a database. Since this is technically fixed "data" I would suggest putting it in
rails_root/db/yaml/
# and you'll have files like
rails_root/db/yaml/measurments.yml
rails_root/db/yaml/locations.yml
# or if you prefer
rails_root/data/yaml/
I'm having huge problems with my populate.rake file - after importing my existing file from my Rails 2.3.5 installation, Rails 3 wants nothing to do with it. I'm getting tens (if not hundreds) of errors in my console, many of them for simple statements, and some even in the middle of a string of plaintext.
Has the syntax changed for Rails 3 populate or, perhaps do I need to install a gem/plugin for it?
Thanks very much.
db-populate is a Rails plugin which uses a populate.rake file, it's not core Rails functionality so yes, you'd need a gem/plugin for it (http://github.com/ffmike/db-populate).
However, since you've upgraded to Rails 3, it might be a nice time to switch to using the built-in Rails seed functionality - that way it's easy to run rake db:setup which will create the db from database.yml, load the schema, and run seeds.rb or rake db:reset which does the same thing after dropping the db. Keeps you from having to maintain third-party code as well. Just food for thought. :)
I found the problem after carefully reconstructing the populate.rake file from a copy. Some of the sample text I introduced into the file had quotes and these were interfering with the quotes belonging to the string itself.
Once Rails interprets the string as having ended, then it logically starts to return errors within the successive strings, which it is reading as interpretable code.
Once I removed all the quotes from within my strings during that reconstruction, the file started working. Thank you Ryan and JenJenut for your replies!
The situation: I used generate scaffold to set up my objects in a new Rails project. Besides doing some migrations, I also directly edited the MySQL tables by adding and renaming columns etc. Now I can't get tests to run because the automatically-generated fixtures do not correspond to the database schema. Perhaps they're based on the original definitions plus migrations, and my migrations to not completely describe the new structure.
I discovered I could use "rake db:test:clone_structure" to duplicate the tables in the test database (db:test:prepare apparently creates them from the migrations?), but I can't figure out how to get the fixtures created from the development schema rather than from the migrations (or whatever is happening).
I got as far as seeing that there is a Fixtures.create_fixtures method, but where would I put it and how would I use it to regenerate all my fixtures?
When working with rails you never do this - "directly edited the MySQL tables by adding and renaming columns"
You create migrations
http://guides.rubyonrails.org/migrations.html
I completely agree that you should not change the database without using migrations, but recreating the fixtures is still a problem that people bump into from time to time. The best solution I have found is here:
http://snippets.dzone.com/posts/show/2525
I'm developing a Rails application and within that application I developed a Rake task that will read entries from a file and store them into the DB. Producing the code was no problem, but I'd like to know, where do I place the file that is read? Is there a convention for that, if yes, what is it?
I know I could have used the seed.rb file but is it ok, by the standards, to load and read a file from there?
Thanks in advance!
Yes, put the data you wish to load in the db/seeds.rb file and to load it run rake db:seed. This is what this file was designed to do.
I don't think there's a hard and fast Rails convention for this case. When it comes to seed data I put mine in a subfolder of db.
The yaml_db plugin dumps/loads content from/to the database from the file
rails_root/db/data.yml i'm not sure if this is by convention, however, the content is db related making the db folder an appropriate choice
Where to put stuff in Rails is a problem that I've been working around for a while. The question is whether your file can fit into one of the existing concerns. For instance, is it configuration information?
Anyway, perhaps a similar fit would be the schema.rb, which is put in the db directory. Do not modify the schema.rb with your data, of course: I'm merely suggesting that the db directory, or a subdirectory, might be a place to put your file(s).
On the other hand, if you don't see any directories that hold anything similar -- it's not one of the main categories in app, nor any of the main categories above that -- then you can just make up a name and use that.
I have two databases in use in a Ruby on Rails application; one is the database for the application while the second is an independent database over which Rails is not given control.
Problem is when loading fixtures into the dev, it tries to run DELETE statements on the tables in the independent database from the connection to the dev database, which obviously errors out.
I don't want Rails to try to do ANYTHING but read the independent database - I especially don't want it trying to delete tables.
Is there a simple way to tell Rails to ignore the models for the second database when loading fixtures?
UPDATE: To clarify, Rails seems to think the tables from the independent database are part of the development connection, though I have specified the correct connection in the model class using establish_connection. As another note, all model classes work precisely as desired from script/console.
rake db:fixtures:load RAILS_ENV=testing
will do the job for database configured as testing in your database.yml
I think you might also be able to accomplish this by adding all the tables in the independent database to ActiveRecord::SchemaDumper.ignore_tables in environment.rb, like so:
ActiveRecord::SchemaDumper.ignore_tables = ['independent_db_table1', 'independent_db_table2']
Okay...my issue was that I used the script/generate to create the models from the secondary database, which also created fixture, schema, test, and migrations files. I had removed the schema, test, and migrations files, but did not remove the generated fixtures (they were empty files) as I did not think it had created any.
After removing all files (including the models) from the secondary database and re-running the migrations for the dev db, I added back only the model files and the database in databases.yml from the secondary db, which solved the issue.
I still can't explain why Rails' rake tasks were looking in the wrong database and I am a little disappointed with rails' addition of the schema_migrations table in the secondary database, which it obviously does not need.
However, it works now.
Delete the model_name.yml file in your test/fixtures directory and Rails will not try to delete these tables.
Better yet, delete all your *.yml files and stop using fixtures entirely.