script/plugin install git://github.com/adamwiggins/yaml_db.git

This command will dump your data

rake db:data:dump

And load it back

rake db:data:load

Beautiful More info here

http://blog.heroku.com/archives/2007/11/23/yamldb_for_databaseindependent_data_dumps/

and

http://stackoverflow.com/questions/490507/best-way-to-export-a-database-table-to-a-yaml-file

IPN delivery failed. Unable to connect to the specified URL. Please verify the URL and try again.

What this actually means is that your server was contacted and your script failed! If you’re using the wrong URL then this error message will apply, however. If you are using the right URL but you have a handler script that fails or is not right in some fashion, it seems logical to report the details of the failure! At the very least, it would be nice to hear

Indeed this URL address is correct, we said hello, but you refused our ‘handshake’. How rude! Link to more info…

When I first tried out the simulator I assumed that the problem was with my DNS. I was testing against a subdomain that didn’t have a cname set up. I wasn’t too sure though if this was the problem. I could visit the URL I specified in my web browser and ping my domain, etc. I eventually got it working after checking some log files. I had to parse my apache logs to fnd that the IPN parameters were indeed posted to my server. This led me to the error in my code.

I’m not blaming Paypal 100%. The error was ultimately on my end. Nonetheless, Paypal did not aid in my troubleshooting endeavor. Instead they exacerbated the problem with an error message that made some assumptions about how I was using their tool. The first being that I understood the IPN protocol. The second, that I understood the way the IPN simulator is meant to work and the protocol under which it operates. Not my error because there is no documentation for the test tool.

Having to parse log files was a needless step in this otherwise simple remote request. Another issue that confounded the problem were the Paypal forums. Some people seemed to think that the IPN simulator was not even operational. Could this be because of misleading error messages?

In my opinion the Paypal documentation is thorough, however, very poorly organized. It seems also that a lot of the Paypal core docs are available in multiple/too many places. I’ve seen the IPN documentation in at least 3 or 4 different areas on the site. Each page adds more information or has a slightly different verbiage to explain the same problem.  Not to mention, there are way too many PDFs available for download! PDFs are great, but the content, organization and display is different from same documentation online.

At any rate, here is a quick Rails controller that will at least get your IPN simulated transactions to return success!

require 'uri'
require 'net/http'
require 'net/https'
class PaymentsController < ApplicationController
  #skip this check b/c post comes in from paypal
  protect_from_forgery :except => [:ipn]
  def ipn
    begin
      if request.post?

      #you need to post back to paypal the name/value string
      #in the same order received w/added cmd=_notify-validate
      from_pp = request.raw_post
      data = from_pp + "&cmd=_notify-validate"
      url = URI.parse 'https://sandbox.paypal.com/cgi-bin/webscr'
      http = Net:HTTP.new url.host, url.port
      http.use_ssl = true

     response, data = http.post url.path, data, {
        'Content-Type' => 'application/x-www-for-urlencoded' }
      end
     rescue Exception => e
     logger.info("Error: paypal transaction #{e.message}")
    end
  end
end

Fixtures are located in your RAILS_ROOT/test/fixtures/model.yml where model.yml is the model in question.
A sample fixture *note: yml files require consistent indentation!

one:
  id: 1
  title: my sample fixture
  description: this is an example of a fixture
  created_at: <%= 2.days.from_now.to_s :db %>

You can load your fixture data like so

rake db:fixtures:load

This assumes that you have a schema migration already raked <code>rake db:migrate</code> and that the attributes in your fixtures map to the correct attributes in your schema. You’ll get an error otherwise. You can also specify the environment when you run your rakes like so…

rake db:fixtures:load RAILS_ENV="production"

As you may have noticed, you can execute Ruby code in your fixtures if you place your code in the normal erb tags
<%= %>. Furthermore, you have access to the Rails api, which gives you handy methods like 2.days.ago.to_s. When creating your fixtures you might be tempted to use <%= Time.now %> for you created_at, updated_at fields. Don’t! Instead, use the rails api like so… <%= 1.month.from_now.to_s :db %> This stores the value in the same way that Rails handles time stamping your models. Otherwise, you might find parts of your application break when running tests against your fixtures because the data types do not correspond.