I've got a fair bit of experience with Ruby on Rails, and I'm taking over development on an existing project created in Grails. The previous developer claims that anyone with Rails experience should be able to do just fine, but I'm banging my head against the wall...
I have the Grails environment correctly configured, and the app can connect to my database. If I were in a RoR project, I know I would just need to run 'rake db:create && rake db:migrate', and I'd be ready to go.
Is there a grails equivalent to bootstrap the database schema?
The default setting in DataSource.groovy of dbCreate = 'create-drop' will create the database tables after dropping previous tables. This works fine for initial development and ok while you're making rapid changes, but once things stabilize somewhat (and at the latest when you're going to production) install the http://grails.org/plugin/database-migration plugin to do proper migrations.
The DSL will look familiar to a Rails developer, and there are convenient scripts that auto-generate migration scripts for you.
Related
I'm coming from the world of python, django where usually our deployment flow was as follow:
tar/gz our code release
unpack on the production
Run db migration manually via south
Run the app
Grails is a little bit different than python/django mainly because the end product is a compiled war. My biggest problem is the manual DB migration. I don't want to run it automatically, one suggested solution that I saw is to use dbm-update-sql to generate manual sql file, but in order to produce it I need my local DB to have the same version as the production DB - I don't like it.
any other suggestions ? it looks to me like the only way to run it manually is to deploy yhe source code on the machine and run the dbm commands there.
You can run dbm-update-sql against the production database, it won't make any changes since like all of the -sql scripts it's there to show you what would be done in the event of a real migration. To be safe, create a user that doesn't have permission to make any changes and use that when you run the script. Create a custom environment in DataSource.groovy with that user info and the production connection info and specify that environment when running the script.
I'd highly recommend not deploying the source to your production systems. Since, you want to manually control your database migrations, outside of the normal flow of a Grails application I'd recommend you look at using liquibase as a stand alone tool.
Obviously since you don't want to manage having a copy of your production schema to diff against this is going to be a lot of manual work for you (e.g. keeping your changes up to date).
The database migration plugin can be used to create sql scripts that you manually run, but you do need a production schema to diff against. I'd recommend you head this route, but you seem set against doing so.
I have a Rails 3.2 application and I have some issues on the production side:
I have a model 'Poject' and did a migration to add a string for 'description'.
running
rake db:migrate
works fine on my developer machine like all the times.
But when I do a cap deploy and cap migrate on the production server I cannot update my
project models which where already in the database. Only new ones work fine.
I'm using postgres 9.1
I don't know what's the issue here since its working fine on my local machine.
Regards
Oliver
I think what you are looking for is cap deploy:migrate.
Run the migrate rake task. By default, it runs this in most recently deployed
version of the app...
You can read more about it here: https://github.com/capistrano/capistrano/wiki/Capistrano-Tasks
Also make sure you are using the right environment while using capistrano
Thank you, I did run the cap deploy:migrate task. But here the problem was that I was validating the existence of a newly created field and this caused the trouble with the records which where already in the database.
thanks.
Is there an issue with developing my site on my macbook and then moving to a server when done? Will there be issues I need to plan ahead for? DB or ruby related maybe? Dependencies or something a server could have different from my dev environment that could cause a nightmare later? I'd rather develop it offline since it'd be faster and wouldn't require an internet connection but in the past I've always done everything with live sites so this would be a first, and I am new to ruby on rails.
Developing locally and then deploying to your server(s) via something like capistrano is standard practise.
It's a good idea to keep your development environment as close as possible to your production environment (ruby versions, database versions etc). Bundler makes keeping your gems in sync easy
I used Heroku for some projects. The deployment was as easy as it could be. I just did a git push and it worked without problems... I really like bundler and rake :-)
Your Question embodies THE way to develop in Rails. Your development environment is an offline representation of what you're production site will be.
A quick workflow analysis for you could be:
rails new ~/my_app -d postgresql; cd ~/my_app; rm public/index.html
Next, create the database:
bundle exec rake db:create:all
Now you'll have the db and app all set up, let's set up your main pages:
bundle exec rails generate controller Site index about_us contact_us
Now you'll have something to see on the site, so run:
bundle exec rails server
This server acts as your offline connection and will handle the rendering of any text, images, html etc you want to serve in your rails app. Now you can join in the debates of TDD, to TATFT or JITT, rspec vs test::unit. Welcome.
Developing locally is definitely the way to go. However, I would look into getting it on production as soon as possible and pushing often. This way you can see changes happen as you make them and are aware of any possible breaking changes.
I use heroku a lot and when I start a new project I push it to heroku almost immediately. While developing, I can publish new changes simply by git push heroku master. Everyone has to find their own workflow, but this has always worked well for me.
If you are interested in Heroku here is a good link to get you started:
https://devcenter.heroku.com/articles/rails3
I have a Rails app that includes pg_search and queue_classic gems. Both of these make use of PostgreSQL extensions e.g., unaccent, pg_trgm and ps-something-something (sorry, not as my dev machine and can not remember).
I'm deploying to Heroku, and having trouble running my migrations that exceute these extensions
e.g.,
def up
execute "create extension unaccent"
execute "create extension pg_trgm"
end
I get the impression that Heroku supports these from here https://devcenter.heroku.com/articles/full-text-search and the fact that Heroku uses queue_classic https://github.com/ryandotsmith/queue_classic.
I've been unable to find any information that explains how to make use of these postgres extensions on Heroku. Or even if they are available for shared databases or only dedicated.
So my questions:
How to I make these extensions available to my app on Heroku?
How do I handle migrations so that these extensions are available to dev
and test environments, but don't break migrations on staging or
production or environments if Heroku is restricting this type of
execution.
Really appreciate any ideas, especially those accompanied with pointers to relevant information/ instructions.
Thanks
If you're using the old standard shared database plans then these probably won't work so you need to look at bumping up to the new shared plans or the production plans.
I'm new to Ruby on Rails (PHP developer here) and I need to edit an existing ROR project. I've been using Aptana Studio for my PHP projects (switched to Zend after Aptana 2.0) but I've kept Aptana RadRails for my ruby projects.
So what I want to do is to get the ROR project from the server (it's hosted on some linux machine) and import it into RadRails for local development. I've downloaded the files from the server and imported them in a new RadRails ROR project but it doesn't work as intended. Is there anything else I should do ? I've read about 'freezing the gems', switching to production mode and dumping the database for a ROR project upon releasing. Are there some steps needed to undo those operations ?
UPDATE:
The problem that I'm having is that I get various errors when trying to visualize in the browser the pages for different controllers.
ActionController::InvalidAuthenticityToken in
No :secret given to the #protect_from_forgery call. Set that or use a session store capable of generating its own keys (Cookie Session Store).
OR
no such file to load -- xml
This error occurred while loading the following files:
hotels_pro
xml
This leads me to believe that (maybe) I haven't got all the files. On the other hand I have double-checked and I have all the files from the server.
Thanks,
A RoR application is more than just the sum of its source files. There's also the database, gems and a server which exist outside the project directory. Without knowing exactly what doesn't we can only speculate which is causing you problems. Being new to Rails, it's probably all of them. If after all this you're still not up and running a few rounds of "Google the Error" should fix you up.
You'll need to set these things up in your development environment before you can proceed. The following assumes you have a working ruby environment: rubygems installed with the rails, and rake gems. Note any commands and paths that follow are relative to the root of your rails project.
Database:
Start with editing config/databases.yml to find out which database your app will try to connect to. Change it if necessary so it names a local database. Create that database, if it doesn't exist with $rake db:create
If you need existing data to test with you can take a dump from your production database and import it into your working database. How to do this is dependent on the type of database in question. Otherwise you can run the migrations with $ rake db:migrate to produce your development database (assuming the previous developer designed the database with migrations.)
Gems:
Check the config/environment.rb, for your list of required gems. Install all these gems if they haven't been already.
If you're using Rails 2.1 or newer, you can streamline this process by ensuring that all gems are required using the newer config.gem 'this_gem' form instead of older require 'this_gem' declaration. Once all required gems are in this form, you can use $ rake gems:install && rake gems:build to ensure they're all installed.
Server:
Is pretty trivial, all rails instalations come with web brick which is fine for development. But mongrel is also suitable.
P.S. If you're not using some kind of revision control it's strongly advised to set something up before starting. It's not a requirement, but it will likely save your ass at some point.