Eloquent is running queries as 'strings' instead of Ints

I believe it's only done for displaying purposes. As far as I can see in the code no integers are converted to strings when building the query. The only thing I can think of is that you are casting the ID by yourself as another type in your model, but it sounds you are not doing that right now.

I think there is no significant performance loss with this as most modern DBMS can handle type casting like that effectively.

But I think adding a $casts property on your Product model should fix that:

<?php

namespace App;

use Illuminate\Database\Eloquent\Model;

class Product extends Model {
    protected $casts = [
        'id' => 'integer',
    ];
}

Laravel will cast the value returned from the database id column to integers.

This is needed as some database drivers returns all values as strings to PHP.

You can read more about attribute casting in the docs:

https://laravel.com/docs/5.5/eloquent-mutators#attribute-casting

@rodrigo.pedra Is right. In this case the database return strings here. I checked it locally with a Homestead box and I'm gettings strings as well.

I tried the casting thing and on a database with a million records I didn't see any performance differences.

Here's my data set I'm calling:

class NodeController extends Controller
{
    public function show(Node $node)
    {

        $nodes = getNodesBelow($node);
        dd($nodes);
        $products = \App\Product::whereIn('node_id', $nodes)
            ->with(['images' => function($q) {
                $q->where('image_type','=','primary');
            }])
            ->paginate(24);
        $subNav = \App\Node::whereNotNull('parent_node_id')->limit(3)->get();
        return view('layouts.node', compact('node','products','subNav'));

    }
}

and $nodes is:

array:48 [▼
  0 => 172456
  1 => 761520
  2 => 11548952011
  3 => 1272251011
  4 => 160354011
  5 => 172463
  6 => 464394
  7 => 6795232011
  8 => 573446
  9 => 6795233011
  10 => 172472
  11 => 3015402011
  12 => 11548957011
  13 => 15874201
  14 => 516866
  15 => 1197396
  16 => 281501
  17 => 3012917011
  18 => 1292110011
  19 => 3015429011
  20 => 1292116011
  21 => 1254762011
  22 => 13436301
  23 => 3151491
  24 => 193870011
  25 => 229189
  26 => 172500
  27 => 3012290011
  28 => 3015422011
  29 => 11036281
  30 => 2998409011
  31 => 1048424
  32 => 1161760
  33 => 572238
  34 => 284822
  35 => 1292107011
  36 => 172480
  37 => 172504
  38 => 300189
  39 => 490499011
  40 => 13983791
  41 => 13983731
  42 => 2348628011
  43 => 2348631011
  44 => 3011391011
  45 => 11041841
  46 => 778660
  47 => 1292115011
]

So I agree, I don't believe I'm purposely setting it as a string.

I'll test the protected $casts to see if that changes it. I might create an issue for the debugbar to clarify the output to ensure users don't get confused like I did.

@rodrigo.pedra I tried that, didn't make a difference for the debugbar display. I do appreciate the idea though. Thanks

@jonathan1 I checked Laravel Debugbar and it quotes all parameters by default before displaying them, see the source code:

https://github.com/barryvdh/laravel-debugbar/blob/master/src/DataCollector/QueryCollector.php#L112

So, it seems it will always show any parameter within quotes.

When I started developing with Laravel and was not aware of Laravel Debugbar I wrote a small package that logs the queries into the log file:

https://github.com/rodrigopedra/laravel-query-logger

It tries to render the query bindings with their proper type. If you are in doubt if Laravel is sending your parameters as integers to the underlying PDO engine you could try that package to check it out.

If you don't want to install a new package just to do it, write a simple event listener and listen to the QueryExecuted event and log the bindings, it is basically what my package does.