The table does not have the specified index: my_index about aws-sdk-ruby-record HOT 12 CLOSED

Thanks @awood45 (and good to "see" you, by the way, we use to be coworkers in logistics :) !)

Also noticed that 1.0.3 has a bug where two consecutive migrations with global index creations would fail because the first would remove some parameters from an option hash from the Aws::Record (

from aws-sdk-ruby-record.

...and that it's broken in 1.0.3. Reopening this for the bug-report side until we push an update.

from aws-sdk-ruby-record.

You should just need to add global_secondary_index to your model file (and depending on your use case, you'll need to run a migration first to create that index on the table).

To query using the index you can specify the index_name in the query method. Something like:

MyModel.query(
  index_name: 'my_index',
  ... #other query parameters

from aws-sdk-ruby-record.

Nevermind, the problem was with the index specified in the .query method which was unknown for the queried table.

from aws-sdk-ruby-record.

Thanks for the update. We're going to be releasing a new feature called TableConfig soon which should make migrations easier to understand and to perform, hopefully that will help somewhat.

from aws-sdk-ruby-record.

Hello again, I did recognize the name. :)

It does look like that was fixed with the TableConfig work, I plan on releasing that this week hopefully as 1.1.0.

from aws-sdk-ruby-record.

Specifically, trying to move away from TableMigration (which I could see having some edge cases) to TableConfig which uses a declarative/smart migration approach.

from aws-sdk-ruby-record.

Still, if you can provide the failing example, I can ensure our test suite covers the edge case in question to avoid regressions. Thanks for that extra report!

from aws-sdk-ruby-record.

Here you are:

class Record
  include Aws::Record

  set_table_name 'RecordTable'

  string_attr :uid, hash_key: true

  global_secondary_index :myindex, hash_key: :uid, projection: { projection_type: "ALL" }
end

def delete_tables
  # Delete the table if already in local DynamoDB
  migration = Aws::Record::TableMigration.new(Record)
  begin
    migration.delete!
  rescue Aws::Record::Errors::TableDoesNotExist
  end
end

def migrate
  migration = Aws::Record::TableMigration.new(Record)
  migration.create!({
    provisioned_throughput: {
      read_capacity_units: 5,
      write_capacity_units: 2
    }, global_secondary_index_throughput: {
      myindex: {
        read_capacity_units: 5,
        write_capacity_units: 2,
      }
    }
  })
  migration.wait_until_available
end

delete_tables
migrate
delete_tables
migrate

Failure/Error:
  migration.create!({
    provisioned_throughput: {
      read_capacity_units: 5,
      write_capacity_units: 2
    }, global_secondary_index_throughput: {
      myindex: {
        read_capacity_units: 5,
        write_capacity_units: 2,
      }
    }

NoMethodError:
  undefined method `database_name' for nil:NilClass

from aws-sdk-ruby-record.

Can confirm at least that the above code works fine against the master branch.

from aws-sdk-ruby-record.

Yes, I confirm this works fine on master. I had to downgrade to reproduce.

from aws-sdk-ruby-record.

I am stuck on this same issue please help me understand how does the table have the specified index? What all I have to change in order to tell table that it is the new index which I have just created in order to query that?

from aws-sdk-ruby-record.