Migrate new table about apartment HOT 12 CLOSED

If I run "rake db:migrate", it will successfully migrate to public schema. But fail when try: "rake apartment:migrate"

from apartment.

did you find an answer for this?
I am having a similar problem while running rake apartment:migrate
rake aborted!
Don't know how to build task 'apartment:migrate'

osx, apartment 0.21.1, .rvm/gems/ruby-1.9.3-p392@npdirector

It seems odd that it cant "find" the apartment rake task

from apartment.

are you using bundle exec rake apartment:migrate ??

Assuming you've added apartment to your Gemfile that is.

from apartment.

thanks brad, and yes. The gem seems to work as normal, except for running new migrations against the other databases.

from apartment.

can you expand on that a bit? You're saying you no longer get the don't know how to build task error?

In order for migrations to run on new databases, the new dbs need to be found when Apartment.database_names is called. You can set this in your config like so:

config.database_names = lambda{ Customer.pluck(:database_name) }

That's of course a made up example, but the gist of it is passing it a lambda that can be called dynamically to query for all existing pg schemas.

Each tenant (ie database, or postgresql schema) maintains its own migration state, so as long as Apartment knows about that db, the migrations will run using bundle exec rake apartment:migrate

from apartment.

sorry for the lack of info, and thank you again.

$ bundle exec rake apartment:migrate
rake aborted!
Don't know how to build task 'apartment:migrate'

Apartment.configure do |config|
    config.excluded_models = ["Account"]
    config.database_names = lambda{ Account.pluck(:subdomain) }
    config.persistent_schemas = ['public']
    config.persistent_schemas = ['hstore']
    config.use_postgres_schemas = true
end

Thanks again.

from apartment.

is it a public project that I can see the source of? As long as apartment is in your Gemfile, then the rake task should work. What version of Rake/Rubygems are you using?

from apartment.

no its not public (yet), but it was originally based around https://github.com/RailsApps/rails-stripe-membership-saas. And after getting rspec to fully run on Rails4, started to implement Apartment Gem to separate accounts (including users table, allowing completely separate users login)

again, rspec fully works creating and dropping schemas, as well as in development using
Apartment::Database.create(account.subdomain)
which to me is odd that *all other parts of Apartment seems to be working with my setup, other than not finding a simple rake task (which I confirmed is within my gem)

Rails 4.0.0.rc2
ruby 1.9.3p392

#database.yml
development:
  adapter: postgresql
  schema_search_path: "public,hstore"
  database: APPNAME
  host: localhost
  port: 5432
  username: MY_USERNAME

from apartment.

ah ok, haven't actually tried Rails 4 yet, but other user's haven't reported any problems.

When I have a chance I'll set up a new Rails 4 project and see if I have the same problem.

from apartment.

Thank you. Im sure its something small, expecially since everything else is working fine.
We're still evaluating to see if this is the solution for this project, but it is very promising (as it is really nicely done).

Just now trying to get it to create the Devise use in the newly created account schema on Account :create.

thanks again for an awesome Gem

from apartment.

ya we had a similar issue. We basically use an after_create that switches into the new schema to create the user.

You can't do any of the automated creation stuff if you're creating tenanted models with the public ones unfortunately.

So you can set, say, an instance variable of a new (unsaved) user, then in after_create you can switch to the schema and save the user.

from apartment.

Ran into this issue after I had added few rake tasks with a file named apartment.rake with the namespace apartment. Looks like rails/ruby doesnt consider multiple rake files/namepaces with the same name?

from apartment.