I call the rails find method a lot during my view. Is this a generally accepted good practice? I'm leaning towards no, but why? Does find call the database each time? Does it cache the result anywhere? I looked up the ruby/rails docs on find but they didn't specify if it actually made a call to the database each time or not.
No, it is not a good idea to call find from the view. It is the job of a controller to load and assemble all the data that a view will need, and pass it to the view for presentation to the user.
Repeated calls to find for the same object should be cached by Rails, so it wouldn't hit the database each time, unless the arguments or other parameters were different.
A realtively easy way to test this would be to fire up a terminal and run rails c. In the console, run the code that returns tplangroup and play with it in the console. You should be able to see database call in the development console.
Based on my experience (not at a computer with rails right now) I think it would hit the database in each of these calls, unless you created tplangroup using the .includes(:tplan) for eager loading.
Hope this helps
Related
In php one can print_r() anywhere in the view, controller, or model. Is there anything like that in rails? I tried to_yaml and inspect. They don't seem to print things out from the model. Is it only allowed to be used in view? If not any example in model or controller?
This doesn't really exist because it's the lest effective way of debugging.
Being able to dump output to the browser depends on where you are. It's trivially easy in views, slightly cumbersome in controllers, and too difficult to be worth-while from models.
Fortunately, there are much better tools than simply dumping things into the browser.
You can use pry to stop mid-request, open a REPL environment and interactively query or modify the state of your running application.
If you simply want to trace the flow of execution through output, use the logger:
Rails.logger.info(my_object.inspect)
Normally you'll identify problems in your model, controller or integration tests long before it becomes an issue. In that context you can use puts to output whatever you want when instrumenting bits of code and it will show up in your test output:
puts object.inspect
Within the Rails operational environment you can use Rails.logger:
Rails.logger.debug(object.inspect)
This will show up in log/development.org where you can see what's going on. It's best to leave this at debug level so it doesn't clutter up your production logs if left in by accident.
Short answer is, you can't. At least not in one line. And not only because this is a violation of MVC, there are also practical reasons that prevent this.
There is no reliable way to output a bunch of data in an arbitrary format and keep it valid. Outputting it in JSON views may easily result in invalid data. So if your debug data can only be handled by a browser, that output should only be specified in views for browsers. Even if none other exist, separate concerns.
There is a substitute, of course. Rails 4.2.0 ships an app template with web_console. All you need to start using it is add a call to console in your views somewhere, like the app's general layout file. If that's actually ERB, add this line below:
<%= console %>
And wherever it appears, you have a REPL in the context of the currently rendered view, where you can easily inspect objects and even perform actions that change your data.
There is also a variety of methods to output data into the server's console or log file. They've been listed in other answers. I'll add a little to the solution involving logger.
Rails Panel. It's a Chrome extension that adds another tab to Chrome Dev Tools (that show up behind F12) named "Rails". For it to work, you need to add a meta_request gem to your app (make sure it's in group development!). Once working, it will show loads of data about how the page was processed:
Time spent fetching data, rendering it
Parameters for the given request
Executed DB queries, duration and lines they've been triggered by
View files involved
Log entries emitted on this request and what triggered that
Errors encountered
This one and some other debugging things are discussed in this Railscast.
I was wondering how to initialize and set a global variable in rails. For example if I was building a pizza delivery system and I want the admin to be able to "close" and "open" the place whenever he pleases.
Setting a global variable is simple, just set it $open = false but that won't help you much in a live application because your application will probably be running across multiple processes (each with its own memory, and therefore its own global variables).
The simplest place to start is to just store this state in your database, and check it on each request that comes in where it's relevant.
$pizza_store = :open
That's all. It's global so it doesn't need to be in any sort of namespace, but I would rethink using global variables for any reason.
Start with code school or something similar to learn basic Ruby, then try a more complete tutorial (the Michael Hartl one is good) and learn 'the Rails way' - because if you want to do Rails, you have to do it their way, or you're going to quickly get frustrated.
In addiction to #smathy's answer, if you wanted to avoid using database, simply File.open a index.html in your /public folder, but, of course, you won't be able to use any dynamically generated content on that page.
thank you for taking a look at this.
I am new to rails, unfortunately. I currently have to implement an endpoint that Superfeedr can push updates to, but that endpoint has to be in a rails controller.
Initially it seemed to me that this should be a background job that runs and the rest of the web tends to agree, but I am being pressured to include this as a rails controller - which confuses me. I am not certain how to include EventMachine in a request/response cycle.
I know the web is full of examples, but none really answer my question with how to route this. I have no idea.
I have a rails controller, called Superfeeds. I want Superfeeder to push updates to something like myrailsapp/superfeeds/
Inside feeds I want to inspect the pushed content, and then write the results of that to another controller that actually has a model and will persist it.
Basically, the controller called Feeds just needs to receive and pass the information along. This confuses me however because it seems to have to implement something which is a long running process inside of a rails controller - and I am not even sure if this can work.
Does anyone know of a way that this has been done with rails, but not using EventMachine as a background job? In the end I really just need to know that this is possible.
-L
Inside feeds I want to inspect the pushed content, and then write the results of that to another controller that actually has a model and will persist it.
Why not do all the work in the one controller? If you're trying to separate out different concerns, you could even use two models - for instance one to do the inspecting/parsing and one to handle the persisting. But rarely would you need or want to to pass data from controller to controller.
I am not certain how to include EventMachine in a request/response cycle.
Never used superfeedr myself, but glanced at the docs quickly - are you using the XMPP or PubSubHubbBub client? I assume the latter? If so, you want to do the persistence (and any other time-consuming process) async (outside the request/resp cycle), right?
If you are using an EventMachine-based webserver such as Thin, basically every request cycle is run within an EM reactor. So you can make use of EM's facilities for offloading tasks such as the deferred thread pool. For an example of this in action, check out Enigmamachine, in particular here. (I believe that in addition your db client library needs to be asynchronous.)
In my Rails app, I changed my model's find method to search into the cache before looking into the database, but I sometime get this error:
Memcached::ServerIsMarkedDead
While waiting for Memcached server to be up again, how should I handle this error and force Rails to search into the database?
Thank you,
Kevin
You should be able to just rescue the exception and search the database in that case.
Rails.cache.fetch encapsulates this pattern in a more generic way, and you may want to look into that instead of hacking find, which is likely to bite you soon when Rails 3 comes out.
This is probably a stupid question but I'll go ahead and humble myself.
The Ruby code in my controllers and models are interpreted so that a HTML result is sent to the browser. Ok, I get that part.
But is there any way for a mailicious user to somehow take a peek at the Ruby code in the controllers and models by bypassing the process that converts or interprets that code before it is sent to the browser?
The reason I'm concerned is I am planning on doing some order processing in my app and if a malicious user was able to do that, they might be able to figure out how to do all kinds of unpleasant things.
Side tip: make sure you use html_escape or h to escape user data and prevent someone from injecting code into your site. For example, use
<%= h(person.name) %> so that someone can't put javascript in the name field and have it run when people view that page.
Nope. Try and navigate to the file yourself in the browser, you won't be able to see it. Your biggest worry should be someone trying to fake out GETs and POSTs because they know how REST works.
Assuming you have things set up correctly, then the web server in front of Rails is pointed to the /public directory. So anything in that directory may be open to direct attack. However, the web server intercepts the HTTP call based on certain criteria and redirects it to Rails for processing.
The architecture of Rails makes it impossible for model and controller code to be exposed to the public. There is a possibility that view code is viewable, but ONLY if you seriously mess up the code (I think). I have never managed to expose code to the client by accident, and I have never deliberately attempted to do so.