Hello, I have a model called Contents, and every content belongs to a Role. The Roles are suposed to be constants (they are always the same and don't change), so I decided to create a migrate to insert the data in the db. The point was that every role has more properties, like priority, and I found it was not a good idea to create a simple class with normal constants. Furthermore, I added a method (const_missing) in the model Role so when I search a constant it checks the db table and creates it dinamically. My problem appeared when I was writing the tests because the migrates don't get executed, and so I don't have any role in my test db. And they are suposed to be constants and be always there. In another project we used fixtures to fix this problem but I don't think that it's the best way because you must keep synch the db and the fixtures. Quite ugly. Thanks in advance for your answers.
on 2009-02-17 13:39
on 2009-02-17 14:13
why would you have to keep your db and your fixtures synched? i would not recommend that at all. but still, fixtures are the way to go (imho).
on 2009-02-17 14:24
On Tue, Feb 17, 2009 at 5:12 AM, MaD <email@example.com> wrote: > > why would you have to keep your db and your fixtures synched? i would > not recommend that at all. but still, fixtures are the way to go > (imho). Hi, you should be able to create a rake task to sync the databases. If you perform a google search: rails test database Good luck, -Conrad
on 2009-02-17 15:04
The problem is not about how I synch the db's, cause I don't think it's a good solution. The thing is that I have some constants ins my application, like you know, TRUE=1 and FALSE=0, and you obviously wanna have them in your tests. The difference is that my constants are my Roles. I decided to put them in the DB because they are not a single value, but something like a constant object. Maybe it's not the best decision, that's why I'm asking. Anyway, I've seen other serious plugins using db tables to store constants. I've been thinking about it and maybe it is a good solution to avoid the migrates to insert that kind of data, but use instead an initializer. It will insert the data the first time in every enviroment. The only think is that it will be probably better to create the table from the initializer (cause it won't insert the data if you haven't executed its migrate) and it might be not very neat.