Query should be used instead of get_item
Lets assume that we have a table with the following structure.
class Website
include Dynamoid::Document
range :page, :integer
field :subdomain, :string
index :subdomain
end
If we do Website.find_by_subdomain('test') we will get the following error: "ArgumentError: a range key value is required for this table". This happens because Dynamoid uses table.items.at (https://github.com/Veraticus/Dynamoid/blob/master/lib/dynamoid/adapter/aws_sdk.rb#L162 ) which would expect to have a range key because the at method returns only one item.
A better approach would be to use the query method from the client which allows to search for an item by HASH even if it has a RANGE defined.
I have tried all kind of ways to do such a query (which is possible in the AWS console) but I haven't got nowhere so far. Please let me know what you think.
In this case, "subdomain" is not the is not the hash key for the Website table, so you can't use QUERY (you must always specify the hash key when doing a QUERY). The index declaration here is building a side table, not doing a direct query against the "websites" table.
That said, if I'm not understanding you correctly, can you express the behavior you want in the form of a spec test? Just a code fragment of the type of query you want to do so that I can better understand your use case.
I noticed after putting this comment that Dynamoid is using the highlevel requests to the Amazon API which doesn't allow to search without a range key. I assume this is new and it will be available once Amazon moves to ClientV2.
BTW: What do you think about using directly the Client instead of the highlevel interface in AwsSdk module?
It's necessary to use the Client directly instead of the high-level API in order to take advantage of secondary indexes, so I think it's inevitable. I have a branch going implementing a Dynamoid::Adapter that uses the V2 client (https://github.com/loganb/Dynamoid/tree/clientv2). Currently, about 80% of the tests pass and there's still a variety of debugging issues that need to be resolved.
Actually there are a lot of issues in the current implementation (at least for indexes). That's why I started to build my own version based on Dynamoid (https://github.com/stefanneculai/dynamodb-rails) and using the ClientV2. One thing that I don't like is that Dynamoid limits the type of a field. IMO, using the ClientV2 with the current adapter would limit the power of DynamoDB.