kitar/laravel-dynamodb

didn't get all the data

Closed this issue · 3 comments

Table json

{
  "AttributeDefinitions": [
    {
      "AttributeName": "ID",
      "AttributeType": "S"
    },
    {
      "AttributeName": "CreatedAt",
      "AttributeType": "S"
    }
  ],
  "TableName": "Sanction",
  "KeySchema": [
    {
      "AttributeName": "ID",
      "KeyType": "HASH"
    },
    {
      "AttributeName": "CreatedAt",
      "KeyType": "RANGE"
    }
  ],
  "TableStatus": "ACTIVE",
  "CreationDateTime": "2023-09-20T09:22:24.651Z",
  "ProvisionedThroughput": {
    "LastIncreaseDateTime": "1970-01-01T00:00:00.000Z",
    "LastDecreaseDateTime": "1970-01-01T00:00:00.000Z",
    "NumberOfDecreasesToday": 0,
    "ReadCapacityUnits": 5,
    "WriteCapacityUnits": 5
  },
  "TableSizeBytes": 33784353,
  "ItemCount": 24403,
  "TableArn": "arn:aws:dynamodb:ddblocal:000000000000:table/UKSanctionList"
}

Model Sanction

class Sanction extends Model
{
    protected $table = 'UKSanctionList';
    protected $primaryKey = 'UniqueID';
    // Name of the sort key (optional)
    protected $sortKey = 'CreatedAt';
    protected $sortKeyDefault = 'CreatedAt';
}

I have more than 40k data in the Sanction table, but I only get 755 data
Is it limited? , so I can't filter the data I want

thank you before

kitar commented

@muhammadaldan I think the issue might be due to DynamoDB's limit on response size. You could try to either refine your query to narrow down the results or implement pagination.

hello, thanks for the answer, so that's actually a limitation of dynamodb?

but when I found UniqueID AFG0001
Sanction::filter('UniqueID', '=' ,'AFG0001')->scan()
the data was successfully found

but where the last data was like this ZIM0006 the data displayed did not appear
Sanction::filter('UniqueID', '=' ,'ZIM0006')->scan()

I think I have to read again about limits and filtering in Dynamodb first

kitar commented

@muhammadaldan Yes, I believe you're right. I'm not quite sure why the last piece of data isn't coming through, but scanning a large table in its entirety can be quite expensive. If possible, I'd suggest narrowing the search using the primary key or a GSI.