Output ActiveRecord MySQL queries to page - mysql

New to rails so bear with me :)
How would I go about appending all of the queries executed by ActiveRecord for each page request to the bottom of the page (i.e. application layout)? Coming from CakePHP, this is a useful tool for ensuring the code I'm writing is efficient.
I know I can change the logger via ActiveRecord::Base.logger = Logger.new(STDOUT), for example, but what would I add in to my layout file to dump a list of the queries being executed? Is there a way for me to configure the ActiveRecord logger to a variable, say in my environment.rb file?

Check out the rails footnotes gem - I think it will likely do what you want here, and give you more features as well. I haven't used it as much lately, but I used it extensively in some Rails v2 apps we had, and I just added it to a Rails v3 application to make sure it still worked as expected (and found some slow queries that need correcting as well! )

Related

meteor reporting of data in existing mysql db. how?

I'm trying to make some reports using meteor and raphael js. I have to report data from an existing MySQL database. I do not wish to write to that database. I need only the "R" from CRUD.
I have thought of various manual ways of: exporting .csv files from the MySQL db via the application itself (Limesurvey) and using mongoimport to populate a MongoDB collection, and then do my CollectionName.find() etc in Meteor.
or perhaps some way of exposing REST full endpoints only to consume data, and use the http package for Meteor.
Is there a good clean solution for using existing SQL data in a Meteor JS application?
How can one use pre-existing SQL data?
(I've no problem with duplication in MongoDB, mind you. however it has to be...)
Thank You
You can do it without any duplication completely from inside Meteor, but you will have to jump through a couple of hoops.
Firstly, use the mysql npm package to query the SQL database. Though Meteor provides Npm to require node packages, I find that using meteor-npm is an easier. Then to do the "R"eading form MySQL, create a Meteor.method on your server which queries the MySQL directly.
Then the second problem is that the mysql package is completely asynchronous. Hence, the execution of the SQL query returns value in a call back and by that point, your Meteor.method call would return leaving the client with an undefined. To fix that issue, we can use Future.
There are a couple of ways of smoothing over this step:
Using `meteor-sync-methods
Spinning out your own version from advice from the issue to allow this natively
Use this easy to implement one-time pattern: "fence has already activated -- too late to add writes"
Hope that helps.

Trying to build rails 3.2 app over existing mysql db

I am trying to figure out how to build a rails app on top of an existing mysql db. I think the best method would just be to create a migration with the same layout as the existing db, but I am not quite sure how to do this, then connect it. I am aware of this post Building Ruby on Rails App with an existing Mysql db
but am still unsure; do I just do this but with the columns I need? Also the main answer to this question is saying that I should make my db a csv and then import it, does anyone have a tutorial or gem they recommend for that?
I have not done this exact task personally although when I modify my databases manually through my mysql client and create backup tables for example, they magically appear in my schema.rb file later down the road when I run some future migrations.
So the following post should help or at least point you in the right direction:
http://tianhsky.ueuo.com/blog/2012/02/20/generate-schema-rb-from-existing-database/
Before that, try to learn more about rails and it's conventions. Probably you'll need to adapt your database scheme.
Or you could start an application and then import the data, even by SQL or by CSV as you mentioned. Migrating data can be a tedious work, but a necessary one.
You can check this gem to see if it helps on your case, because it will depend on your actual schema.

Ruby on Rails3 and MySQL query best practices

I'm trying to transition from PHP to Rails and was wondering what the best practices are. I have all the data I need in MySQL and would like to make simple queries and display them using the kinds of niceties afforded by ActiveRecords. I'm familiar with the MVC paradigm and am trying not to rely on my knowledge of PHP, but how, for example, would I be able to do the kinds of things I used to do with:
$query = mysql_query("Select * from table where name = 'blah');
if I already have that data (I can see generating a scaffold if I didn't have pre-existing data). Do I create a scaffold and then import my data into it? or do I write raw MySQL queries in Ruby?
Thanks!
First, remember that Rails is a web dev framework, not a scripting language like PHP. Ruby is the scripting language. PHP has frameworks as well, but just wanted to make sure you realize the difference between the one and the other.
Most basic and medium-complexity queries in Rails are handled via the ActiveRecord methods and helpers. You'll find that you'll be writing much less actual SQL, as that is generally abstracted away into the framework.
For instance, assuming the name of your model is City, the equivalent of your query in Rails would be:
City.find_all_by_name('blah')
How does this work? When you create a model in Rails you usually subclass ActiveRecord::Base. Built into that class is a plethora of functionality that, for one thing, examines your data table and builds dynamic finders for each of the fields and combination of fields on the table.
Since you already have all the data, you're going to be overriding some of the conventional functionality of Rails in order to get everything working. For instance, Rails assumes by convention that there is a primary key field named "id". Also, Rails assumes that the table is named as the plural form of whatever the model class definition is. All of these things are defaulted by convention, but can be overridden. If you were building from scratch and following conventions, all this would sort of happen as a matter of course.
Based on your question, I think you need to spend some time with some basic Rails reading material and some specific info about ActiveRecord and Rails models, so that you can come up to speed on these major differences between Rails and standard PHP application. If you don't get that straight from the beginning, then you are going to build a lot of PHP-style Rails stuff and you won't be taking full advantage of what Rails and Ruby have to offer. In the end, you'll say "what did I do all that for, it's all the same."
If, instead, you try to start from the Rails Way of doing things, you'll find that Ruby and Rails offer a lot.
If you are working with an existing database then you are going to have a hard time forcing Rails to play nicely with it. Rails power (some might call it a weakness) is that it favors convention over configuration. In other words, it really expects you database columns to be structured a certain way. Stray from the convention and you lose all the reasons for using Rails in the first place.
When you start a new rails project and use the migrations rails makes sure that the structure is as it expects.
If you are moving an old project to rails then I would strongly suggest writing a function to import that data into a rails-created DB. This will save you a lot of heartache in the long run and will allow you to take full advantage of Rails' strengths.

Migrating subsets of production data back to dev

In our rails app we sometimes have db entries created by users that we'd like to make part of our dev environment, without exporting the whole table. So, we'd like to be able to have a special 'dev and testing' dump.
Any recommended best practices? mysqldump seems pretty cumbersome, and we'd like to pull in rails associations as well, so maybe a rake task would make more sense.
Ideas?
You could use an ETL tool like Pentaho Kettle. Once you have initial transformation setup that you want you could easily run it with different parameters in the future. This way you could also keep all your associations. I wrote a little blurb about Pentaho for another question here.
If you provide a rough schema I could probably help you get started on what your transformation would look like.
I had a similar need and I ended up creating a plugin for that. It was developed for Rails 2.x and worked fine for me, but I didn't have much use for it lately.
The documentation is lacking, but it's pretty simple. You basically install the plugin and then have a method to_sql available on all your models. Options are explained in README.
You can try it out and let me know if you have any issues, I'll try to help.
I'd go after it using a Rails runner script. That will allow your code to access the same things your Rails app would, including the database initializations. ActiveRecord will be able to take advantage of the model relationships you've defined.
Create some "transfer" tables in your production database and copy the desired data into those using the "runner" script. From there you could serialize the data, or use a dump tool, since you'll be dealing with a reduced amount of records. Reverse the process in the development environment to move the data into the database.
I had a need to populate the database in one of my apps from remote web logs and wrote a runner script that fired off periodically via cron, ftps the data from my site and inserts the data.

How can I store my Rewrite Rules in a database?

Im developing a new site, and I'd like to store my rewrite rules in a database, instead of right in the .htaccess files.
I have another site that uses Opensef (http://sourceforge.net/projects/opensef/) with a Joomla! installation that is doing this, but im not even 100% how it works underneath the hood.
How can I store these rules in a database, query for them on request and rediret to the clean URL if found? Is there a better way to do this instead of loading up a .htaccess file (there may be 1000's of entries)?
Thank you,
You can get mod_rewrite to generate a map from external source such as executing a PHP or Python file which can get the data from the database and create a mod_rewrite map.
http://httpd.apache.org/docs/2.0/misc/rewriteguide.html
(See right at the bottom)
For example
RewriteMap quux-map prg:/path/to/map.quux.pl
Good Luck
Assuming all these pages are ultimately in Joomla, I think using .htaccess or mod_rewrite is a mistake.
I think you're much better off learning how Openserf works. I'd imagine it has a little piece of code that runs early on for every request that queries the database and issues a Redirect through PHP if there's a hit. A further advantage of this approach is that it should even be possible to have Joomla rewrite links on its pages to point to the clean version in the first place, saving the user an unneeded redirect
Incidentally, this is how the Pathauto module in Drupal does it, and I use that all the time on some pretty high volume sites with many thousands of pages.
I think that the best approach to use rules stored in a database is:
Store the rules in your database through your admin panel of your site.
Then after updating database, generate a new .htaccess using the rules in DB using your server-side language solution.
Replace old .htaccess with new one.
This avoids the server load. It's similar to Aiden Bell solution.
Grab the UrlRewriteFilter, butcher it to use a DB, and use that in Tomcat instead of Apache.
Tomcat is a fine web server and can do many things Apache can do (like FastCGI for PHP), and writing stuff like this for it is trivial compared to writing such things for Apache.
What you probably want is a single rewrite rule to handle every unknown request that comes in and then pass that to a small script that will handle the lookups & generate redirects. You could even skip the rewrite rule completely and use the Apache ErrorDocument directive to pass unknown URLS into the script.
You've been pretty slim on the details of what this 'new site' is but, you might want to consider building yourself a Front Controller for the app & having it take care of all the incoming URLs. Many (most?) web app frameworks take this approach.