<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>active_record &#8211; redpanthers.co</title>
	<atom:link href="/tag/active_record/feed/" rel="self" type="application/rss+xml" />
	<link>/</link>
	<description>Red Panthers - Experts in Ruby on Rails, System Design and Vue.js</description>
	<lastBuildDate>Tue, 13 Sep 2016 06:27:31 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=5.2.7</generator>
	<item>
		<title>application_record.rb available since rails 5</title>
		<link>/application_record-rb-available-since-rails-5/</link>
				<pubDate>Tue, 13 Sep 2016 06:27:31 +0000</pubDate>
		<dc:creator><![CDATA[coderhs]]></dc:creator>
				<category><![CDATA[Beginners]]></category>
		<category><![CDATA[Rails]]></category>
		<category><![CDATA[Rails 5]]></category>
		<category><![CDATA[active_record]]></category>
		<category><![CDATA[application_record]]></category>
		<category><![CDATA[base]]></category>
		<category><![CDATA[database]]></category>
		<category><![CDATA[model]]></category>
		<category><![CDATA[models]]></category>
		<category><![CDATA[pollute]]></category>
		<category><![CDATA[rails]]></category>
		<category><![CDATA[universal]]></category>

		<guid isPermaLink="false">https://redpanthers.co/?p=509</guid>
				<description><![CDATA[
				<![CDATA[]]>		]]></description>
								<content:encoded><![CDATA[<p>				<![CDATA[Those who have been starting with Rails 5, must have noticed the new <strong>application_record.rb</strong> file present in your model folder. And all new models seems to be inheriting the <strong>application_record.rb</strong> instead of the <strong>ActiveRecord::Base. </strong>This is done so that we don&#8217;t pollute the <strong>ActiveRecord::Base</strong> namespace with our own extensions.  Before when we require something, say an extension to the ActiveRecord itself we used to have it included using the following code.


<pre class="lang:ruby decode:true">module NewFeature
  def to_do_something
    puts "I am doing something new which Active Record coudln't do before"
  end
end
ActiveRecord::Base.include(NewFeature)</pre>


Now the problem with this approach is that when we use rails engines this NewFeature gets added in there as well, and it could end up doing things that we didn&#8217;t expect.
With the new application_record.rb, which would be inherited by all the models, we need to include the new module at the <strong>ApplicationRecord</strong> and it would be available as the new feature of <strong>ActiveRecord</strong>. Every new engine generated using <strong>rails plugin new</strong> would also be having their own <strong>application_reocord.rb</strong>
One more point to note is that we can place application wide hooks in this file. So if you were to do


<pre class="lang:ruby decode:true ">after_create do
  Rails.logger.info "[DataEntry] A new record has been created"
end</pre>


it would be triggered when a new record is created in any of the models of the rails application.]]&gt;		</p>
]]></content:encoded>
										</item>
		<item>
		<title>after_create vs after_save vs after_commit</title>
		<link>/after_create-vs-after_save-vs-after_commit/</link>
				<comments>/after_create-vs-after_save-vs-after_commit/#comments</comments>
				<pubDate>Thu, 28 Jul 2016 06:46:38 +0000</pubDate>
		<dc:creator><![CDATA[coderhs]]></dc:creator>
				<category><![CDATA[Rails]]></category>
		<category><![CDATA[Training]]></category>
		<category><![CDATA[active_model]]></category>
		<category><![CDATA[active_record]]></category>
		<category><![CDATA[after_commit]]></category>
		<category><![CDATA[after_create]]></category>
		<category><![CDATA[after_save]]></category>
		<category><![CDATA[callbacks]]></category>
		<category><![CDATA[database]]></category>
		<category><![CDATA[mysql]]></category>
		<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[rails]]></category>
		<category><![CDATA[Ruby]]></category>
		<category><![CDATA[transaction]]></category>

		<guid isPermaLink="false">https://redpanthers.co/?p=371</guid>
				<description><![CDATA[
				<![CDATA[]]>		]]></description>
								<content:encoded><![CDATA[<p>				<![CDATA[<code>after_save</code>, <code>after_create</code> and <code>after_commit</code> are called active record call backs in rails. They get executed when we work on the database, similarly we also have before_* callback and callbacks on destroy as well. In this article I will explain you about the difference between *_save, *_create and *_commit callbacks.
The purpose of each as per rails docs:


<blockquote>after_create
Is called after <code>Base.save</code> on new objects that haven‘t been saved yet (no record exists)
after_save
Is called after <code>Base.save</code> (regardless of whether it‘s a create or update save)
after_commit
Is called after the database transaction is completed.</blockquote>


Now to explain the real difference between the three, we must first explain about database transaction. They are a protective block around a group of sql statements, that are permanent only if all of them succeed in a single atomic statement.


<pre class="lang:default decode:true">User.transaction do
    # update company
    # update hr_department
    # update user_table
end</pre>


When rails execute a create, the <code>after_save</code> and <code>after_create</code> would be called within the transaction block of the create statement. So they will be executed before executing the sql statement to make permanent changes in the DB. If the query fails, then no change will happen to the DB, but we would have executed the instructions of the after_create and <code>after_save</code> block.
Where as after_commit, is called after the execution of the final/outer transaction block. Thus the changes in the DB would be permanent.]]&gt;		</p>
]]></content:encoded>
							<wfw:commentRss>/after_create-vs-after_save-vs-after_commit/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
							</item>
	</channel>
</rss>
