Introducing SimpleDB::Class
I've been working on a suite of modules for the past couple of months to make building applications on top of Amazon's SimpleDB as easy as building applications on DBIx::Class. It's called SimpleDB::Class.
It gives you an object relational mapper style interface to SimpleDB, which is heavily borrowed from DBIx::Class. It uses Memcached to speed up queries, increase capacity, and get around most of the stickiest problems with eventual consistency.
SimpleDB::Class also hides all of the things that most new developers find difficult about SimpleDB, things like cascading retries, next tokens, and the pseudo rest-like protocol for interfacing with SimpleDB. Not to mention handling searchable/sortable dates and numbers. As a developer, you simply give it some data or ask it for some data, and all those things just happen automatically behind the scenes.
There are even many nice utility functions like max and min, which are posted in questions to the SimpleDB forums all too often.
I've still got a decent todo list for it (things like cnames, pagination, and auto-sharding), but it's a good working solution right now, that's being used in our environment.
If you have a wishlist for features, or better yet you have patches, let me know. I'm happy to include them. You can download it from the CPAN, or read about it online at: http://search.cpan.org/~rizen/SimpleDB-Class/lib/SimpleDB/Class.pm
Inspired by this post (thanks JT!), I went looking for more info and found the Perl implementation samples at Introduction to Amazon SimpleDB.
That was a good start though I made a few notes along the way.
Hope this helps,
recordtary
To get the 'Create' script to work on my Windows ActiveScript Perl 5.8 install I had to make some changes:
It seems that the Digest::SHA1 is not robust enough and so Digest::SHA is the successor. The sample script uses Digest::SHA, so the verification of presence of Digest::SHA1 was useless. Go find/install Digest::SHA.
Then, we find that a module the script uses, 'Client.pm', invokes URI::Escape::uri_escape_utf8. This was not in my (older) installation of URI::Escape. So, go off to 'ppm' and there's no listing there. Fine, grab the source from CPAN, create a file 'Escape.pm' and (oops, there's that old version, quick, rename the old one) and save the source into the file. Now things work....
Except. The 'Listing Domains' instructions seem to have been copied from the 'Creating a Domain' instruction. It says to look for 'invokeCreateDomain' rather than for 'invokeListDomains'. I notice that the Java instructions mention the correct method....
In 'Putting Data into a Domain', i.e. 'PutAttributesRequest', it seems to be able to add multiple values to an attribute of an object. Isn't this bad form? (e.g. Size/Small, Size/Medium, Size/Large) Looks like the Glossary has a term for this: multi-valued attribute
Seems sloppy for the script to keep doing 'my $request' instead of doing 'my' once and then re-using the variable later. (But thanks for the script, thanks for the script.)
Where the previous lab steps had us remove the comments for lines like:
the sample script here already contains this (uncommented) line(s). (In fact each of the five invocations of 'invokePutAttributes' has its own instance of this line.)
In 'Getting Data from a Domain', I see that the 'Name' values (like 'Category') are case sensitive as is the domain name of 'MyStore'. Command keywords are not case sensitive, i.e. Where, where, WHERE all work. Doing a GET on the same request seems to process faster as though the search was cached.
In 'Deleting Values from an Attribute', it looks like running a 'deleteAttributes' request against an item whose attribute does not contain that value is okay; nothing happens. (Which is expected.) Hmm, the error reporting does not seem to report trouble with deleting a value for a nonexistent attribute, i.e. 'colorr'. Deletion only succeeds when using case sensitive attribute name and case sensitive value.