customink / secondbase

Seamless second database integration for Rails.
MIT License
220 stars 31 forks source link

invoking db:secondbase:migrate overwrites secondbase/schema with primary #49

Closed iiwo closed 2 months ago

iiwo commented 7 years ago

Invoking rake db:secondbase:migrate or rake db:secondbase:rollback causes secondbase/schema.rb to be overwritten by primary database schema (in place of secondary). Invoking rake db:migrate after this fixes this and causes proper schema (secondary) to be saved. Not a huge issue, but causes some confusion. Tested on rails 4.2.7.1

metaskills commented 7 years ago

I think we want to only support the primary interfaces exposed by Rails. Hence, running individual tasks is not guaranteed to work. That said, if you think we can do this easily it would be neat to fix. But my hunch is that the we need the task to run fist and patching requires that we get smart by knowing what Rails core tasks are doing... not easy to maintain.

iiwo commented 7 years ago

Thanks for fast answer on this.

running individual tasks is not guaranteed to work

For me issue was just that there's nothing on Readme about that. There's just a mention saying Not all base database tasks make sense to run a mirrored SecondBase task.. and db:secondbase:rollback is listed there so I was confused because I thought something is not configured right or not working correctly, and didn't found an issue reported on that so had to triple check things.

Ultimately that's not a big issue and just having it reported now even if as "won't do" and closed will save people some time if they stumble upon this situation.

I'll try to see if I can fix that and push a PR, or maybe just some update to the Readme if that's a complicated thing to fix.

justinperkins commented 6 years ago

In environments that rely on the schema to load up the database (test, for example), this issue is a real problem.

metaskills commented 6 years ago

this issue is a real problem

What keeps you from running standard db:migrate task?

justinperkins commented 6 years ago

You're right, we tweaked our schema loader to run that post process, fixed the issues. Was not completely obvious at the time what to do.

metaskills commented 6 years ago

Cool, thanks for replying @justinperkins. FYI, in test envs you should technically do db:setup which does a schema/structure load. Migrations are not to be used for setting up the DB. In fact, those should be deleted form the repo when production gets them. HTH.