PHP Warning: Illegal offset type in isset or empty

[foxted]

Hi there,

First of all, thanks for working on this package, it is awesome.

However, when trying to retrieve an item with a query, I get this error:

PHP Warning:  Illegal offset type in isset or empty in /home/vagrant/Sites/Liftmap/vendor/laravel/framework/src/Illuminate/Support/Str.php on line 487

My query is the following:

$item = (new Model)->find($id);

When I try to fetch it using a where query:

$item = (new Model)->where('id', $id)->get();

I get a different error:

PHP Notice:  Array to string conversion in /home/vagrant/Sites/Liftmap/vendor/baopham/dynamodb/src/DynamoDbQueryBuilder.php on line 741

I am actively trying to find the cause of it all, but so far, only querying all the records is working. If anybody has an idea on why this could be happening, it would be much appreciated.

Thanks!

[baopham]

What is your $id? Is it a string or? Can you show me your model class? What version of the library are you using?

[foxted]

My $id is an integer, I am using the autoincrement ID from another resource in a SQL database. Here is my class code:

<?php 

namespace App;

use BaoPham\DynamoDb\DynamoDbModel;

class Results extends Model {

    protected $table = "local_results";

    protected $fillable = ['id'];

}

I am using the latest version I think, 4.1.0.

[baopham]

Thanks :)
More questions...
What is you Dynamodb table schema? What is the output of $model->getKeyNames()

I will do some troubleshooting in about 10hours...

[foxted]

The schema only contains id, created_at and updated_at for now.

EDIT: I reverted my branch to finish up some work for now, so I had to remove the package.

[zoul0813]

Not sure if this is related, or a separate issue ... but I'm receiving a similar "Illegal offset type" error with Elasticquent. The code worked prior to the latest updates (getKeyName() now returns an array for composite key models).

Elasticquent has the following code:

$key_name = $this->getKeyName();
$attributes = $hit['_source'];
if (isset($hit['_id'])) {
  $attributes[$key_name] = is_numeric($hit['_id']) ? intval($hit['_id']) : $hit['_id'];
}

When the model being queried has a composite key, this throws an exception ...

I believe getKeyName() should be reverted back to it's original configuration where it returned the primary key only (this is the expected result as Eloquent doesn't have support for composite keys).

Due to incompatibility with an unknown number of packages that rely on the Eloquent model's "getKeyName" method, I recommend re-introducing the getCompositeKeyName() and getCompositeKey() methods.

[baopham]

That should be a separate issue. Because the model in question doesn't have composite keys.

[baopham]

I believe getKeyName() should be reverted back to it's original configuration where it returned the primary key only (this is the expected result as Eloquent doesn't have support for composite keys).

hmm, that is debatable because for a composite model, the primary key consists of 2 keys:

So in DynamoDB context, getting the key for a composite model should return both partition and sort keys. As for your Elasticquent issue, could you create an issue for it? would be great if you explain the use case why you need the partition key only, is it just for hashing? if so, we can find way for that.

[baopham]

@foxted so I tried to reproduce and could not. Here are my steps:

1. Create a table with hash key id (of type number)
2. Seed one item
3. Run Model::find(1)

All is successful...

I am wondering if there's something wonky with that particular record that you are trying to find.

You mention that getting all items works. What happens if you do Model::take(1)->get()->toArray()?

Can you show me the result of the above call? and if it also fails, can you show me the result of Model::all()->toArray() - assuming that there is no sensitive data.

btw, new version is up, feel free (recommending) to update to version 4.1.1

[foxted]

I will try version 4.1.1 and see if it fixes the issue. Model::all()->toArray() works fine, it is only happening when using find() for some reason. I'll keep you updated.

[baopham]

I'm closing this one since we haven't been able to reproduce this. Feel free re-open or create a new issue for this.