Biggest mistake of my life. SimpleDB is a great SIMPLE database. I, however, failed to consider 2 matters before I began using it.
First. It is slow to update_attributes. Not literally, it’s just like every database. But what is different here is that whenever you make a POST request to make changes or save a new item in a domain, it has multiple instances of your database all around Amazon’s infrastructure. There’s a few second delay to update all the instances of your database.
I used simpleDB for my application that sells ‘buttons’. I use postgresql for the user and newsletter_subscriber model and simpledb for the buttons and orders model. And this is the problem I faced, my application uses paypal express as the sole payment solution. What PayPal does after a successful payment is to send a long parameter containing the detail of the transaction. I, then, save the Success parameter to the database. What happens in my controller after successfully creating a new order is to redirect_to new#buttons action, which basically allows users to immediately make and customize their own button. But before loading the new buttons action, I have a before_filter that checks that this request belongs to a valid paid order (based on paypal’s return parameters). This is where it fails. The paypal transaction successfully gets process, and my application saves the successs value into the database. But my new#buttons action fails the before_filter that checks if the value of successully_paid is true. In other words, somehow SimpleDB still passes the old ‘success’ status to my application. It has indeed successfully updated to the new value. But one of simpleDB’s disadvantage of being ‘widely available’ across their infrastructure is the lag in updating all the instances of our database.
Oh well, I bypass this by not checking the success status. Instead I just check that the order is valid (so the payment could still have failed) but when hitting the create#action, I check that such an order exist, is valid and has been paid. Some funny person can try and input a valid order number and get into the new#buttons action. But he’s ability to do so if quite slim considering that I also check that the order belongs to the current user and has been used to redeem buttons.
Over the next few days, I might implement all this logic into my model as a before_save filter. Just to tidy up my controller actions and also to keep the logic at the database level.
The second problem with simpleDB is that, since it’s not a relational database and my code had a far amount of relational matters, it’s pretty inefficient that I have to do a lot of the logic in my application layer, causing unnecessary amount of code.
I’ll probably rewrite my whole application and move Orders model to postgresql and keep buttons model with SimpleDB. 🙂