You have to be careful though, if you're looking only for gas giants, and there happen to be other items with a density property (like subclasses of GasGiant), then you'll get those back too. So it might be safer to run your search like this:

Given the previous example of using recast_using to store multiple object types in the same domain, you can do something similar to make sure that some object types get stored in a different domain. You simply add a new set_domain_name command to the subclass:

In SimpleDB, the primary key (aka id or ItemName) is not actually part of the data stored in the item, so you can't use it in a where clause or order by clause. However, there is a special fucntion called itemName() that allows you to do just that. Assuming you were searching a domain here's what that might look like:

$books->search(where => { 'itemName()' => ['in','x','y','z'] });

The above statement says to return any items that have an id of x, y, or z. This can be useful if you just want to retreive a specific set of items in a single request. Or if you actually specifiy the ids at creation time, and have some sort of logic in them, you may be able to do other things.

That says return all items where color is green ordered by id. If you're using the auto-generated ids that SimpleDB::Class::Item provides for you, this is a way to produce a semi-random ordered result set.

it creates the item and inserts it into the database. Sometimes you want to create the item in advance, play around with it, and then decide whether to insert it into the database. This is fairly easy, but not entirely intuitive. Let's assume you have a SimpleDB::Class::Item subclass called Book that you've created. Do the following:

Yes. In a version number like 1.0402 there are three pieces of information that can be gleened.

The first is the number before the decimal (1). That is the API version number, and only changes if the API or data storage mechanisms change in an incompatible way to previous releases. Therefore if you write code against version 1.0001 and then sometime later 1.5702 comes out, you can be reasonably sure your code will still function as you expect it to on 1.5702. However, if 2.0000 comes out, all bets are off.

The second number (04) is the feature release. That number is changed every time a new feature is added to the system and released. It gets reset to 00 if the API version number changes.

The third number (02) is the bug fix number. That number is changed every time a new release comes out that only contains bug fixes. It gets reset to 00 if the feature release number is incremented.