using the railties patch described in this post: slow rails stack, i'm noticing that the step "set_routes_reloader" is regularly taking upwards of 3 seconds.
is this expected? if not, what might i be doing wrong and/or how do i go about figuring out if i'm doing something wrong, etc.
In our case the problem was that we were defining too many routes. The set_routes_reloader step loads your routes (as you might guess). We got a lot of mileage by adding the appropriate :except/:only arguments.
Something that may help you is the traceroute gem which provides you a list of routes that do not have an associated controller action. I wrote a one-time script to process our traceroute output and update our routes.rb file. You can find it here.
Related
We're at a point in our development where there have been many different fingers in our Rails pie, and there are things we know exist currently that are not being used, etc. What I'm looking for is some way of programmatically determining if there are any orphan routes in the controllers, maybe something that will take the output of rails routes and see if there is anything extraneous in the code. Any thoughts?
It sounds like what your looking for is known as code metrics, there's one solutions in particular that I can think of that sort of covers what you need. It's known as the rails_best_practices gem, one of the many things it checks for is unused controller actions. In addition it will inform you that auto generated routes (e.g., index, show, edit, update, etc..) require restricting when not all of them are used.
For instance the following line will create seven RESTful routes for your Foo controller, regardless of whether they're actually ever implemented or not:
resources :foo
But if your controller only makes use of say the index, show, new, create actions it will tell you to add the :only directive to your route mapping for those actions.
There might be some additional options out there that are more inline with what you need, I recommend taking a look at the Ruby Toolbox's code metrics category and seeing what's out there. Here's the link: https://www.ruby-toolbox.com/categories/code_metrics
I'm trying to profile some of our Rails controllers using Mini Profiler, but I think I'm trying to use it for something it isn't built for. I've got it profiling SQL queries just fine, but I need to break down the non-SQL code, because we're seeing a lot of chug in some pages, but the SQL doesn't seem to be the problem.
Here's a screenshot of what I'm talking about: http://cl.ly/image/2J3i1C1c072O
You can see that the top level (Executing action: show) takes 9136ms to complete, but the queries executed are only a fraction of that total time. I suppose what I'm asking is if there's a way to display more "detailed" information about the code being executed, or if I need to find a different tool to use. New Relic isn't an option, unfortunately.
Thanks for any help.
You can insert custom steps in the areas you think are responsible.
# in your initializer
Rack::MiniProfiler.profile_method SomeClass, "method"
# or
Rack::MiniProfiler.step "some step" do
# your code
end
Additionally you can run ruby-prof to figure out what is going on everywhere and then strategically instrument.
In my Rails application I'm using Rack::Timeout to solve an issue described in this here. Works fine so far, but I have 2 questions regarding this:
What is the best way to test the timeout handling (using rspec)?
According to the documentation, Rack::Timeout uses threads so I have to make sure my app is "thread-safe". I know what this basically means in theory -- I have to make sure that no problems occur when two threads operate on the same data at the same time -- but I'm not sure where exactly I have to ensure that. The static datastructures/methods I'm using should not be problematic, but I'm not sure with the database. Does it (or the ActiveRecord classes) need additional configuration?
I having some trouble trying to figure out how to implement a Rails 3 multi-page form with file uploads, where each step is handled by the update/edit actions in the controller.
Ryan Bates provided his wonderful screencast for how to to do multi-step forms using sessions, as well as a brief description on how to accomplish something similar by saving to the database on the initial step and then perform updates on each successive step. I have also read his gist giving a more detailed explanation of some different options on how to create a multi-step form (I am leaning toward option 1).
But I am still quite a bit lost when it comes to the actual implementation of a multi-step form. My goal is to use carrierwave for the file uploads (images), and perhaps workflow by geekq for the state machine to help with with validations at each step.
Just to be clear, I am currently trying to create an entry in the database on the initial step of the wizard, and have each successive page update the model.
Any ideas?
An example or a point in the right direction would be greatly appreciated.
Thanks!
Note: I have read another post where they mention something about a key/value data-store, but that unfortunately is a bit over my head...
Key-Value store or SQL for that matter are very loosely tied to your actual problem. Those are just a different approaches on how your data are actually stored in the backend. Using one way or another doesn't really make a difference in your case.
As for the actual question I think its too general for SO. Multistep forms tend to be very different one from another. There is no "one good way" of doing those.
The reason you are not getting any answers on this is probably because there is no real question asked. What you should do is to try to do actual implementation and post more specific questions when hitting the wall somewhere.
In the end - I believe the multistep forms are not really the best idea when it comes to usability. Of course there are valid reasons to use them in some cases, but you should really think twice if there is a way to avoid those in your case.
One of the problems I had while ago with forms and uploads was the validation (It isn't related to Multi/Single step specifically). Normally when validation fails user would have to re-upload the file. Fortunately in your case this not much of an issue, since Carrierwave handles that automatically.
There is a development_structure.sql inside my /db folder of my rails application (rails 2.3.4, ruby 1.8.7) and I am not sure exactly what it does.
Is it needed for some specific environment? (I think I read somewhere that it's used for tests)
Do I need to add it to my git repository?
This post has been used as a reference by a coworker of mine, but the two answers are not exact or informative enough.
development_structure.sql is a low-level dump of the schema, which is necessary when you start to use proprietary database features - either you want to or not, you're going to use them at some point.
Regarding the question of storing it or not, there's some debate. Here is an informative post: http://www.saturnflyer.com/blog/jim/2010/09/14/always-check-in-schema-rb/.
And my take on this follows.
The objective of the development_structure.sql is to sync, for any given commit, the database structure with the code, without having previous knowledge of the schema structure, that is, without having to rely on a pre-existing state of the schema to get the new one.
In a nutshell, by having a schema structure available, whenever you change branch/commit, you load it directly and forget it.
This is mostly valid for dynamic and "crowded" projects, where different branches have differences in the underlying schema structure.
Without having the schema structure stored, you would need to always use an existing reference schema in your database, and migrate it back or forward every time you change branch/commit; several real-world cases can make this process inefficient (e.g. when another branch doesn't have some migrations you currently have, or some migrations can't be rolled back).
Another problem is automated builds, which suffer from the same problems, and even worse, they can't apply manual changes.
The only downside is that it requires a certain habit, which is, to store it every time you run a migration. Easy to say, but also easy to forget.
I don't say you can't live without development_structure.sql - of course you can.
But if you have it, when changing branch/commit you just load-and-forget; if you don't, you [may] have to go through a series of manual steps.
You should not add it to your git repository.
It is a file created automatically by rails when you run migrations with your database.yml configured to connect against a mysql database.
You can view it as an alternative to schema.rb
I believe you can force rails to create it by adding in your environment.rb:
config.active_record.schema_format = :sql
When present this file is used for example by:
rake db:test:clone_structure
Edit
Relevant section in Ruby On Rails Guides.
http://guides.rubyonrails.org/migrations.html#schema-dumping-and-you
They recommend to check it into source control on the wiki.
I personally like to keep it out of it. I like to be able to run all migrations very quickly. It is for me a good sign. If migrations become slow I feel like I am not in total control of my environment anymore. Slowness in migrations generally means I have a lot of data in my development database which I feel wrong.
However, It seems to be a matter of personal taste nowadays.
Follow your instincts on this one.
It's created when you run a rake task to clone your development database to your test database. The development database is outputted to SQL which is then read in to your test DB. You can safely delete it.
In rails 3, you don't even have to write this line,
config.active_record.schema_format = :sql
You can generate this structure.sql file by simply running the above rake command mentioned above