Is storing version of Rails application in database is the right way ? Rails version it's a release production code version incremented every time we are doing deployment. It used for informational purposes only. Generally people recommended setting up version in config/initializers/version.rb but IMO it could be hard for change automatically during deployment (adding file to .gitignore or not and etc.) Using AR record we could easily had ApplicationVersion.last.to_version in our code. What do You thing about this ?
How about writing it out to a yaml file that you could generate during deployment? It'd be a simple matter to generate that during deployment, especially if you're using a tool such as capistrano.
My concern about writing it to a file is that the production database isn't a concrete resource. What if you have a crash and need to restore the database? The database potentially will report a different version than the current state of the code.
Related
I have to do a lot of conditioning of the data that will seed my rails database. This is a one-shot activity before deployment, never used after deployment, but I want to keep the programs I use for it within the projects configuration management (mainly for the sake of an audit trail for where the seed data came from).
Where is the canonical place in a Rails app for such support files that don't form part of the application?
Seed data should go in db/seed.rb. You can learn more about seed data in the docs.
The problem with adding all these items to your repository is that not only will it make the checked in code large, also you will have to clean the code each time after deploy.
I do not think such items should be checked in. Personally, I place all such items in public data, upload it for first deploy and then next deploy will no longer have this folder as the deployment using capistrano will not link to the data folder anymore.
This way the data can stay in the shared folder on the server should you need it again but not in your repository.
I am trying a number of different applications into my rails project. For security reasons, I am storing any sensitive keys as environment variables.
This is easy to do with Heroku but on the local environment side I find my windows environment variables starting to pile up. If I happen to have two projects with facebook authentication now I have to name them uniquely on my computer not to get mixed up with each others, which then means I have to rename them in my rails projects, which then means I need to rename them in Heroku... AH
Is there an easier way of doing this such as a configuration file that is added to gitignore, or is that still not quite safe?
What's the best practice for this?
Rails 4.1 comes with secrets.yml, which is where you would put these. Please see this section of the Rails 4.1 release notes for more info.
So I am starting to learn rails, with a php and front end background. I created a new rails project and that was going well enough, until I downloaded another rails app off github and installed all dependencies and gems...anyway these problems have been my undoing for the last two days...I would really appreciate some clarification.
How exactly do you manage local databases for a development version as opposed to those external databases for a live version?
Will Rails build a local database automatically after an application is imported from Github for instance? Or does one have to be created manually, also should it have the same authentication credentials that the downloaded uses to talk to its database?
Also, after I downloaded PostgreSQL and its gem, I can no longer start rails server for my old rails project, or for my new one for that matter, both get these errors:
gems/actionpack-3.0.16/lib/action_dispatch/http/mime_type.rb:98: warning: already initialized constant PDF
gems/activerecord-3.0.16/lib/active_record/connection_adapters/postgresql_adapter.rb:950:in `initialize': FATAL: role "postgres" does not exist (PGError)
Since you're using postgresql (which possibly shared by several applications), and in my understanding, two rails applications usually do not share namespaces other than database, I guess you've not modified config/database.yml file.
By convention, the default development database name is development, so, if you haven't touch the configuration file, the two applications share same database options, cause conflicts.
I usually modify the database name to development_SomeApplicationName (replace SomeApplicationName with some meaning application name to differentiate database name) just after creating new application.
I'm writing a command line program that maintains state in a database. Are there any templates for setting up an app folder structure similar to Rails? I.e. have infrastructure for:
Having all files in lib, app, etc directories auto-required in all of those files
Having multiple database environments like dev, test, prod
Having Rake tasks for runnning tests in a test database
So, this is essentially a Rails layout but without anything to do with serving web-pages.
Once I have this kind of app, I want to distribute it via a gem, but have it initialize a database in the user's home directory when installed, maybe in ~/.myapp.
What would you recommend?
If you just want a gem based application you could look into this guys development here:
http://www.acmesprockets.com/node/24
You could just forgo Rails and using stock ruby with OptionParser and ActiveRecord or Sequel.
I've been using Wordpress for awhile, it's installed on my own server, and one of the features I most love about it is how every time there is a new version it alerts you within the app's web-based admin and with one click I can upgrade the app. I don't have to get anywhere near a console.
Personally I wouldn't mind updating manually, but I can see how this could significantly affect the adoption of a piece of software. I'm working on creating a full-featured ruby on rails forum software and I would love to figure out how to include this feature. Any ideas if this could be done with rails?
Could a rails app modify it's own files? If it did, would the server need to be restarted?
To complicate things further, what if the app was deployed from a repo. Could the rails app check in a commit of itself after updating?
Maybe packaging the core of the app as a gem would be simpler? Then maybe the upgrade would not actually modify the rails MVC stack (the rails app would just be super-basic), instead if the forum was all contained within a gem then all it has to do is trigger a 'gem update [name]'. If this occurred, I don't think the Gemfile would even need to be updated. Would a server restart even be required to load the updated gem?
Ideas or feedback on any of this?
Rails files can be modified and even deleted on production - in my case aplication is still working unchanged as all classes are cached in memory. It means Rails instances must be restarted to take new change.
I suppose WordPress is Perl via CGI and you just drop application into web directory to have it working immediately - same with updates - just overwrite files and Apache picks them up immediately.
In case of Rails is that you don't know target deployment architecture thus restarting application may not be trivial. E.g. with passenger I can just do touch tmp\restart.txt and then all instances are killed and started again. Some deployments may need init.d script restart invocation.
Maybe you could recommend or prepare a ready to use deployment model which supports autoupdate. In other cases users could do updates manually.