I apparently haven't set up my associations properly; records aren't being saved out to where I thought they would be. Checking the output on the Rails server (rails s), I see lots of SELECT statements but no INSERT or UPDATE statements.
Is there a way to view these types of queries with the rails server? Ideally I would like a solution that doesn't involve installing third party components... but if that is the only way, I might consider it after I throw a tantrum.
If you did not change your configuration, all SQL statements appear in your server console by default.
3 things you can do:
1- You can check your config/environmets/development.rb file if there is a config.log_level statement. And eventually set it to :debug:
config.log_level = :debug
2- Also be sure your rails server runs in development, you can see that in the first lines in the console, or add RAILS_ENV=development in your rails s command
3- Place some were in your code (preferably in top of an entry function of your controller) User.first.touch (or using any other model of your choice) this is to confirm the UPDATE statement is correctly appearing in the logs
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 rails which seemed to be working previously but now after some changes when I go to the root page it takes it infinitely to load it, it just doesn't load it. There're nothing useful in the console either. How can I find out what prevents it from loading the main page? Is it about profiling?
Check your Rails logs, eg. development.rb. You can put logger.info, or puts statements in your environment.rb, development.rb and application.rb files to see how far Rails is getting in the boot process. You can also create a dumb initializer named 00_start_init.rb with a logger.info or puts statement to see if you're getting as far as initialization. I've found that useful before.
To really understand where you application is hanging, you need to understand the Rails initialization process. Here is the documentation for Rails version 4.2. http://guides.rubyonrails.org/v4.2/initialization.html. Similar documentation exists for every version of Rails. You can take advantage of understanding the boot sequence by placing log statement at various point in the process.
I'm assuming you're in the development environment. If so, and the console loads, it's likely not a configuration problem. It's more likely a problem with your controllers or models. If the console won't load to a prompt, then it's likely a configuration problem in application.rb, development.rb, an initializer, etc.
You mention profiling, but provide no details about it. I can't even guess what you're referring to, so the answer is "maybe?". If you can post the code changes you made since the app last loaded in the browser, that would make it much easier to help you trouble-shoot.
This is the strangest bug I've ever encountered
I am using the Best In Place gem in my Rails app in order to allow in-place editing of a page title. The in-place editing works, and the new title gets changed in the database, but when I refresh the page, it reverts back to the old title. I don't even understand where it's getting the old title from, since it's not stored in the database anymore.
When the page is created, it is automatically given the title "Untitled Page". When I change the title to say, "Title", and look at the row for the page in the DB with the postgresql admin program, it does indeed change to "Title". But when I run Page.find(1).title in the rails console, it returns "Untitled Page"
How could this be?!
Is your app running in production mode?
The PG response and console response cannot be different unless they are being executed on two different databases.
Check that your database config is using the same database as the one you are manually connecting to when browsing PG.
Ensure that when you run the rails console you specify the environment (in case your default is not what you are running on):
$ rails c production
$ rails c development
If both of the above don't help, please post the log snippet of this action. Might be that the transaction is being rolled back. If you are using .save or .update_attribute without the "!" then this won't throw an error. This is highly unlikely though, since you are saying that the database has updated data.
Fixed it. The reason was that I was using after_initialize to set the automatic properties, which gets called whenever the ActiveRecord object gets initialized. What I really wanted was after_create. I use after_create to call a function called set_properties, where I set things like self.title, and then at the end of the function, I call self.save, which is required for the properties to get saved into the DB.
I'm considering using Ruby on Rails for my next project. Understanding the deployment of a rails website is easy enough to understand (sounds like I'll be using Phusion Passenger)
But now I'm trying to figure out the database. I see a lot about "database migrations", which allow me to update the database using ruby code. I also see that I'm allowed to create both an up and down variant of these migrations.
However, I can only fathom how this works cleanly in a single direction. Imagine if I suddenly say "The color column cannot be null". So, the up will make it required and give all NULL entries a default value. But what will the down do? If you care about it being identical to how it started, you can't just set the default values back to NULL.
This doesn't really matter much for releases to production. That will likely just be done in a single direction (in the up direction). However, I want to use Gerrit for code reviews as well as setting up a bot to run a build before allowing check-ins...
So how could that work? From one code review to the next, the build server will check out the new set of code, and run the migrations? But when this happens, it won't even retain the migration code from before, so how could it run the down steps? As an simpler example, I do not see how I could check out an old version of the code and "db migrate" backwards.
Yes, you can't check out an old version of the code and then run a down migration from a newer version of the code. You would need to run the down migration before rolling back to the older code.
There are many, many cases where a down migration is just not practical or possible. That's not necessarily a bad thing. It just means that you have defined a 'point of no return', where you won't be able to restore your database to an earlier state.
Migrations like creating a table or adding a column are easily reversed by simply destroying that table or removing that column. However, if you are doing something more complex, such as adding default values or moving data around, then you can tell Rails that it's not possible to reverse this migration:
def down
raise ActiveRecord::IrreversibleMigration
end
I would recommend that Gerrit should never assume anything about the database. It should start with a fresh database each time a new version is deployed, and run db:migrate to run all your migrations. You can use gems like factory_girl to populate your app with demo data for testing purposes.
is the console in rails (~ rails c) dynamic? For example; if I open the console and then make changes to a model will it pick these changes up or do I have to exit out of the console and run rails c again for it to pick up the changes in the model?
You will need to call the reload! method in the console to reload the changes. This method's magic is automatically called by rails server in development mode.
As a comment's pointed out beneath and another answer here, if you change things to do with the environment of the application, such as adding new gems to the Gemfile, making changes to anything in config or adding a new plugin then you'll need to restart the console. Any changes to app will be reloadable with reload!
If you were using this particular way to test that a method was working, I wouldn't. Tests (as in, the Test::Unit or RSpec) variants are much nicer because you have a reproducible way of running them again and again. rails console is great for one-off testing, but if you want to write a maintainable application then write tests.