Following the Railscast episode on copycopter, so I set up my copycopter server on heroku. Everything works great, until AWS goes down and brings down heroku. At that moment, all my copycopter text reverted to the default text I had entered on my html pages.
Is there a way I can store the results from a successful call to my copycopter server on my rails server so that, in case of another heroku outage, my text will still be from copycopter?
Could you use I18n cache by passing a cache store or even I18n memoization? In my Rails app, I have I18n::Backend::Simple.include(I18n::Backend::Memoize) in an initializer, so all the translations are cached in memory after the first hit.
I18n also supports using a real cache store so you could use memcached or redis to store the copies which would avoid the issue you mentioned when copycopter server goes down.
From copycopter readme, you can also export the blurbs:
Blurbs are cached in-memory while your Rails application is running. To export all cached blurbs to a yml file for offline access, use the rake task:
rake copycopter:export
The exported yaml will be located at config/locales/copycopter.yml.
Related
Is there a way to manually inject a translation through the Rails console ?
Suppose I am working on a dev environment, and I want to test some code in a production console (eg to test some statistics on real data).Problem is, the code I want to test relies on new translations that didn't exist (or were changed) in the production environment.
So my code returns a lot of translation_missing
Can I inject the missing translations ? Via a hash or a YML file ?
I18n.load_translations(hash_or_file)
Usually Application instances that serve http requests (for example running under Unicorn/Puma) are not available via Rails console. When someone login to production server and type $RAILS_ENV=production rails c it starts another application process. Translations dictionary is a kind of in-memory cache and usually it is not possible to change that cache for/from another process (in general). You can reload translations only for application instance that started by Rails console, but not for running server.
Only one way to hot reload translations is adding kind of a hook into source code of application to re-read YAML file, but it seems better just restart application server.
UPDATE: For testing purposes I18n cache could be modified like:
I18n.backend.send(:translations)[:en][:date][:formats][:default] = "%Y-%Z"
I have a Heroku app that is running on the Cedar-10 stack which will soon be deprecated. I am following the Migrating to the Celadon Cedar-14 Stack guide and have created an instance of my app on the new stack. However, this has also created another (empty) PostgreSQL database automatically.
Can I upgrade to the new stack but continue to use the existing database?
When I delete app on the old stack, will it delete the database that is associated with it automatically?
I see that the database URL is set in the environment variable $DATABASE_URL - does that mean I can somehow update that and "link" the old database to the new app?
When searching for information on this I've come across heroku's pg:copy and pg:transfer directives, but it seems strange to duplicate the database when it is working fine, and has a paid "upgrade" and backups already associated with it.
The problem with the configuration variable approach
While it is possible to share a database between two applications in Heroku by copying the DATABASE_URL configuration variable of the first application to the second, only the first application will have a primary connection (add-on) to the database.
If you remove the first application, your database will disappear from the postgres dashboard in Heroku. Although it seems the second application will still be able to use the database. (Tested on 2015-10-25.)
It is also worth noting that:
Heroku do reserve the right to change database URLs as required. If this occurs, it will cause your secondary connections to fail, and you'll need to update the URLs accordingly.
What this means is that if Heroku decide to change the URL for your database, your new application will fail, and since the database is now gone from your dashboard, you will not be able to retrieve the new URL without approaching Heroku. (If at all.)
This implies that there is a more intrinsic connection between an application and its database than merely the DATABASE_URL, and it might not be the best idea to use this as a mechanism for transfer.
An alternative approach using PGBackups
Heroku official documentation recommends using the free PGBackups add-on (which, honestly, you should always be running anyway) to transfer data between Postgres instances. The tool uses the native pg_dump and pg_restore tools.
Particularly, you can use the PG copy feature, described below:
PG copy uses the native PostgreSQL backup and restore utilities. Instead of writing the backup to a disk however, it streams it over the wire directly to the restore process on the new database.
They conveniently provide a means for you to copy a database between applications with a single command, and without any intermediate storage required:
As an alternative, you can migrate data between databases that are attached to different applications.
To copy the source database to the target database you will need to invoke pg:copy from the target application, referencing a source database.
Example:
heroku pg:copy source-application::OLIVE HEROKU_POSTGRESQL_PINK -a target-application
Where source-application is your existing stack, and target-application your newly created one. Not relevant to you, but still worth mentioning, is that any existing data in target-applications database will be destroyed.
After this, you might need to promote the database in the new application like so:
heroku pg:promote HEROKU_POSTGRESQL_PINK
You certainly can change your configuration variables to point from the new app's database to the existing database. I've done this before without issue (just make sure you have a fresh backup).
So within your new app run heroku config. You'll see a reference to your database in DATABASE_URL. You can then change the value with:
heroku config:set DATABASE_URL=<existing-database-url>
At that point you'd have your old app and new app pointing at the same database without issue. As you said, you're paying for the database upgrade on your existing database so deleting your old app shouldn't delete the database; if it does (again you have backups right?) that would be the time to contact Heroku!
If you're not comfortable working with the command line, you can also change the values in your app's Settings tab on the Heroku app dashboard.
With all of that said, you shouldn't actually need to create a new app in order to upgrade your stack. Again, I've done a stack upgrade before and you ought to be able to do it in place; which the Heroku docs confirm.
Although #Drenmi's approach is probably the safest option it is possible to transfer database "ownership" between apps.
Make sure you make a backup first.
In Heroku databases are treated as Add-Ons. So when you for example push a rails app heroku will add a postgres db addon to the app.
First use heroku addons to get a list of the addons attached:
$ heroku addons --app old_app
Add-on Plan Price
─────────────────────────────────────── ──── ─────
heroku-postgresql (resting-fairly-4672) dev free
└─ as HEROKU_POSTGRESQL_CYAN
We can then attach the database to the new app.
heroku addons:attach resting-fairly-4672 --app new_app
And detach it from the old app.
heroku addons:detach resting-fairly-4672 -app old_app
See https://devcenter.heroku.com/articles/managing-add-ons
I am unable to see anything in the cache from the console in either development or production.
For development, I have turned on caching and set it to memory store, in production I use the dalli gem and Memcachier on Heroku.
Every key I try comes back nil.
However, in development, if I put in a binding.pry before somewhere I'm doing a Rails.cache.fetch, I can do a Rails.cache.read there and see something returning, and indeed if so, execution does not go in to the fetch's block.
From the console, if I try Rails.cache.reading the same key that just returned a cached result in the pry breakpoint console, I get nothing. It seems like the console has a separate cache, as if from the console I do Rails.cache.write("whatever", "blah") and Rails.cache.read("whatever"), I get "blah" in return, as expected.
Is there a way to experiment with the cache for a running server from the console?
Change your cache store: the memory store just stores everything in the process's memory, so every instance of the application will have a separate cache. In particular the console won't see anything that is set from the running web application.
You could use the file store (which stores data in temporary files in tmp) or you could also use dalli store locally - memcached is very easy to run.
I'm completely new to Ruby on Rails, have never worked on it, but I am supposed to take over somebody else's old project. He designed a webapp that logs into a website/server online, extracts data from it daily and performs calculations. However, the application has not been running for quite some time, so now when it tries to display statistics, the page crashes. It uses data from a 5 week period and currently only has data for 2 days.
I need to manually insert data for the missing weeks in order to get it up and running again, but the problem is I don't know how to find/access its database, nor how exactly to use Ruby on Rails. I found several files in the db directory of his project, however they were mostly .sqlite33 files or just 'files'. I downloaded sqlite precompiled binary for Windows and tried to use it, but not sure what to do. I also downloaded and tried using SQTView to open the files to change the tables, but I have had no luck.
How can I tell which file is the main database and how do I edit it? And what are .sqlite33 files? Thanks.
EDIT
The application produces a
TypeError in HomeController#index
"nil can't be coerced into Float"
It links the error to a line in the code, but the only reason the error happens is because there is no data in the table for the time period that the variable in this line of code tries to use. That is why I want to manually update it with values.
I think that Sqliteman might do the trick and thank-you for explaining all of this to me. I just have to confirm it works after editing.
EDIT2
Okay, so I had a small revelation while experimenting on his app. It turned out that the page crashed because of empty values for full weeks. If I used the app to gather data for at least one day per week up until this week, then the app worked.
Is there a way I can populate all the missing days without having to manually click the days in its calendar because it takes a good 20-30 seconds for it to load?
Thank you very much for your help.
A Rails application's database is defined in config/database.yml - though the database itself and the scheme are in the db folder. In database.yml you'll find three database configurations - development, test and production - so make sure to choose the right file.
I've never heard of .sqlite33 files, but to edit SQLite files manually I recommend SQLiteMan. But I don't recommend editing it manually.
What I do recommend is to check if you are running the app in development or production mode, as the two mods use different databases. Try to run it in the other mode.
If that doesn't work, try saving a copy of the database files, and running the commands:
bundle install
bundle exec rake assets:precompile
rake db:migrate
rake db:migrate RAILS_ENV="production"
(if you're using Linux, you might want to also run the first command with sudo)
Those commands make sure all the required gems are installed, that the precompiled assets are up to date, and that the database fits the schema. If you are running that application on the same machine and with the same database as the ones the other guy was using, than those commands shouldn't be necessary, but if you have moved the application to your own machine, or used an used an outdated db file, than those commands might fix the crash.
At any rate, if you tell us what error the application is producing we might be able to provide more assistance.
Rails appends a timestamp to js and css files to force cache refreshes while in development mode. While this is appropriate most of the time, it backfires when using CSSEdit, for example, that does not take the timestamp append into consideration.
If you attempt to create a new style or edit an existing selector it will attempt to reload the page each time, even though you've opened a file once. This is a conversation I had a long time ago with Jan, however I've never seen a mechanism added to address this situation.
Is anyone aware of either:
A) a hack to allow CSSEdit to cut off the ?##### timestamp or
B) just simply temporarily disable rails timestamps via the rails server command (or perhaps just throw an awk into it to change a config file via a script to start the rails dev server on localhost)?
RAILS_ASSET_ID='' rails s actually does the trick for anyone needing to work with CSSEdit and Rails to temporarily disable the modification postfixes when dealing with the cache-buster.
This is handy since it's a temporary solution and will go back to the normal operation when you go back to running rails without the RAILS_ASSET_ID command prepend.