Query by "id" field problem

[LNDev]

• Laravel-mongodb Version: 5.4.1
• PHP Version: 8.2.8
• Database Driver & Version:
  MongoDb 1.21.0

Description:

The issue arises when queries are performed using the "id" field on collections where the values of _"id" and "id" are different. In such cases, querying by "id" returns an empty result.

For example:

ExampleModel::where('id', $id);

returns an empty result.

I think this happens due to three main reasons:

First, the method getRenameEmbeddedIdField() returns true by default if the rename_embedded_id_field setting is not defined in the config/database.php file.

Second, in the methods "aliasIdForQuery" and "aliasIdForResult", if rename_embedded_id_field is not defined or is explicitly set to true or explicitly set to false (in any way, then), the "id" field is always internally converted to "_id" (in root). As a result, any query targeting "id" actually ends up querying "_id".

Third, during the compilation of the "where" clause by the "compileWheres" method, the "id" column is again transformed into "_id". This means that any condition written on "id" is effectively applied to "_id" instead.

[alcaeus]

This means that any condition written on "id" is effectively applied to "_id" instead.

This is intended behaviour and not a bug.

[spidfire]

I've got a database in which that is not the case and the _id is different to id. But the the feature the disable this is not working properly.

The feature i mean:
https://www.mongodb.com/docs/drivers/php/laravel-mongodb/current/fundamentals/connection/connection-options/#disable-use-of-id-field-name-conversion

[alcaeus]

But the the feature the disable this is not working properly.

From the docs (emphasis mine):

When using Laravel MongoDB v5.3 or later, you can disable the automatic conversion of id to _id for embedded documents.

The feature is not designed to disable the handling in root documents; it's to allow for having embedded documents with an id field, as these don't implicitly have an _id field like root documents do.

If you have _id and id fields with different values, take a look at which value your application relies on. If it's the _id field, you should remove the id field and ever forget it existed. If your application relies on the value in id, update the _id field as indicated in this comment, then remove the id field and ever forget it existed.

[LNDev]

@alcaeus Maybe I didn’t understand :-( . Are you suggesting to physically remove the "id" field from the collections?

[alcaeus]

I'd like to see someone physically remove something from a database, but essentially, yes.

The fact that some parts of Laravel don't use the primaryKey field defined in your model but rather hardcode id for the primary key always caused issues, in most cases leading to two identifiers being present in the document. We worked around this by treating id as an alias for _id. If you happen to have both, put whatever you want your identifier to be into the _id field, then remove id from your document. Just don't physically remove that area of your hard drive, but you probably know that ;)

[LNDev]

@alcaeus I can’t modify the database... it’s not mine :-( ... I can only read from it, so this is a big problem for me, since I’m using Laravel 12 and I’d like to keep the vendor modules always updated to the latest version.