Getting “Lock wait timeout exceeded; try restarting transaction” even though I’m not using a transaction

You can set variable innodb_lock_wait_timeout=100 for lock time to 100 sec.

mysql> set innodb_lock_wait_timeout=100

Query OK, 0 rows affected (0.02 sec)

mysql> show variables like 'innodb_lock_wait_timeout';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| innodb_lock_wait_timeout | 100   |
+--------------------------+-------+

The transaction which is timeout, try to lock table which is hold by another process. and your timeout variable set with little number of second. so it shows error. You can see more status by the command.

SHOW ENGINE INNODB STATUS\G 

You can see list of locked tables by-

 show open tables where in_use>0;

Now see the thread which is using this table

  show full processlist;

now you can kill that thread or wait to complete it.

=====================================================

 

You are using a transaction; autocommit does not disable transactions, it just makes them automatically commit at the end of the statement.

What is happening is, some other thread is holding a record lock on some record (you’re updating every record in the table!) for too long, and your thread is being timed out.

You can see more details of the event by issuing a

SHOW ENGINE INNODB STATUS

after the event (in sql editor). Ideally do this on a quiet test-machine.

Advertisements

Difference between has_and_belongs_to_many vs has_many through

As far as I can remember, has_and_belongs_to_many gives you a simple lookup table which references your two models. Here you just store the both models(join table) ids.

For example,

Stories can belong to many categories. Categories can have many stories.

Categories_Stories Table
story_id | category_id
has_many :through gives you a third model which can be used to store various other pieces of information which don’t belong to either of the original models. Here join model have references your two models and other column also we can use. Here the system is allow validation too.

For example

Person can subscribe to many magazines. Magazines can have many subscribers.

Thus, we can have a subscription model in the middle, which gives us a similar table to the earlier example, but with additional properties.

Subscriptions Table
person_id | magazine_id | subscription_type | subscription_length | subscription_date

Irb/Bundle Exec Irb/Bundle Console/Rails Console

  • irb is the basic Ruby console. It ignores your Gemfile, and only core Ruby classes are accessible without require-ing them. It can’t easily load gems that Bundler installs outside of RubyGems’ load path.
  • bundle exec irb is like irb, if you also required bundler/setup. You can only easily require gems that are in your Gemfile.lock, but you can load those gems no matter where Bundler put them.
  • bundle console is like bundle exec irb, if you also called Bundler.require. All of the gems in your Gemfile, except the ones marked require: false, can be used without requiring them. It’s really convenient when you’re writing your own gems, or working on non-Rails code.
  • rails console is like running bundle console inside a Rails app, if you also required config/environment.rb. You can play with your entire Rails app, autoloads and database connections work, and everything’s hooked up the way you’d expect. If you’re working in a Rails app, this is the most helpful kind of console.

Web Server / App Server / Passenger / Rack

What’s a web server?

A web server is a program that takes a request to your website from a user and does some processing on it. Then, it might give the request to your Rails app. Nginx and Apache are the two big web servers you’ll run into.

 

If the request is for something that doesn’t change often, like CSS, JavaScript, or images, your Rails app probably doesn’t need to see it. The web server can handle the request itself, without even talking to your app. It’ll usually be faster that way.

 

Web servers can handle SSL requests, serve static files and assets, compress requests, and do lots of other things that almost every website needs. And if your Rails app does need to handle a request, the web server will pass it on to your app server.

 

What’s an app server?

An app server is the thing that actually runs your Rails app. Your app server loads your code and keeps your app in memory. When your app server gets a request from your web server, it tells your Rails app about it. After your app is done handling the request, the app server sends the response back to the web server (and eventually to the user).

 

You can run most app servers by themselves, without a web server in front of it. That’s probably what you do in development mode! In production, though, you’ll usually have a web server in front. It’ll handle multiple apps at once, render your assets faster, and deal with a lot of the processing you’ll do on every request.

 

There are a ton of app servers for Rails apps, including Mongrel (which isn’t used much anymore), Unicorn, Thin, Rainbows, and Puma. Each has different advantages and different philosophies. But in the end, they all accomplish the same thing – keeping your Rails app running and handling requests.

 

What about Passenger?

Phusion Passenger is a little unique. In “standalone mode,” it can act just like an app server. But it can also be built right into a web server, so you don’t need a separate app server to run your Rails apps.

 

This can be really convenient. Especially if you’re planning to run a bunch of apps and don’t want to spend time setting up an app server for each one. After installing Passenger, you just point the web server directly at your Rails app (instead of an app server), and your Rails app will start handling requests!

 

Passenger is a nice option, but having a separate app server can be still be good. Keeping the app server separate gives you the flexibility to choose an app server that best fits your needs, and you can run and scale it on its own. Still, I’m going to try it again the next time I deploy a new small app. I’m hoping it’ll make it easier to deploy future apps to the same server.

 

What about Rack?

Rack is the magic that lets any of these app servers run your Rails app. (Or Sinatra app, or Padrino app, or…)

 

You can think of Rack as a common language that Ruby web frameworks (like Rails) and app servers both speak. Because each side knows the same language, it means Rails can talk to Unicorn and Unicorn to Rails, without having either Rails or Unicorn know anything about the other.

 

How do they relate?

So, how does this all fit together?

 

Out of these pieces, a web request will hit your web server first. If the request is something Rails can handle, the web server will do some processing on the request, and hand it off to the app server. The app server uses Rack to talk to your Rails app. When your app is done with the request, your Rails app sends the response back through the app server and the web server to the person using your app.

 

More specifically, Nginx might pass a request to Unicorn. Unicorn gives the request to Rack, which gives it to the Rails router, which gives it to the right controller. Then, your response just goes back through the other way.

 

This overview might be simplified. But even just knowing these categories will help you put the software you run into into the right mental buckets.

 

After you understand how app servers and web servers fit together, it’ll be a lot easier to debug server problems when you have them. You’ll know all the different places you could look, and how they interact. And once the next interesting app server arrives, it’ll be even easier for you to swap it in!

How to load CSS and JS based on company / user

How to load CSS and JS based on company :-

application.html.erb :-

Top of the file,

<%= stylesheet_link_tag ‘application’ %>
<%= load_default_theme_css -%>
<%= load_customer_specific_css(current_company) -%>

Down of the file,

<%= javascript_include_tag “application” %>
<%= load_default_theme_js -%>
<%= load_customer_specific_js(current_company) -%>

application_helper.rb,

All files are present inside the ‘/home/selva/Project/main/shared/theme’ folder
application location – /home/selva/Project/main/sub

def load_customer_specific_css(company)
stylesheet_link_tag “/theme/#{company.theme}.css”, :media => “screen, projection” if company.presence.try(:theme)
end

def load_default_theme_css
stylesheet_link_tag “/theme/#{Rails.application.config.default_theme}.css”, :media => “screen, projection” if Rails.application.config.default_theme.present?
end

def load_customer_specific_js(company)
javascript_include_tag “/theme/#{company.theme}.js” if company.presence.try(:theme)
end

def load_default_theme_js
javascript_include_tag “/theme/#{Rails.application.config.default_theme}.js” if Rails.application.config.default_theme.present?
end

How to generate CSV in rails

How to generate csv and fetching the data from xls/fetching from db are given below,

users = User.first 10
file = “#{Rails.root}/public/user_data.csv”
column_headers = [“User ID”, “First Name”, “Last Name”, “Email”]
CSV.open(file, ‘w’, write_headers: true, headers: column_headers) do |writer|
users.each do |user|
writer << [user.id, user.login, user.name, user.email]
end
end

How to send mail with attachment in ruby

We can send mail with attachment in ruby, given below

require ‘mail’
options = { :address => “smtp.gmail.com”,
:port => 587,
:domain => ‘gmail.com’,
:user_name => ‘dev@gmail.com’,
:password => ‘password’,
:authentication => ‘plain’,
:enable_starttls_auto => true }

Mail.defaults do
delivery_method :smtp, options
end

mail = Mail.new do
from “dev@gmail.com”
to “selva@gmail.in”
subject “This is a test email”
body “Hello”
add_file “#{Rails.root}/public/report.csv”
end

mail.deliver