Avoiding overwriting andWhere()/orWhere() with where() in ActiveQuery when scoping data

[yiisoft]

Avoiding overwriting andWhere()/orWhere() with where() in ActiveQuery when scoping data

[mtangoo]

I think that will better be alleviated by making it clear in documentation than what you are suggesting.

User have to know how he shouldn't use where, and having a note or a warning should suffice.

I don't believe it's necessary.

If it's really that necessary, which I don't believe it is, then adding what you are explaining as an example or even better adding to Yii cookbook.

[arogachev]

I don't get need of that. Could you provide an example with some data?

[YasserHassan]

For example, you could have a base class BaseModel that scopes all records by current user like where(['user' => Yii::$app->user->id]) or andWhere(['user' => Yii::$app->user->id]). You'd expect that any child class like Messages, Invoices, ...etc, to be scoped by the current user. If during execution at any point after scoping where() is used, user scoping would be lost. This is not a far-fetched scenario especially with new programmers who know nothing (yet) about the base class.

While where() would overwrite other where(), andWhere(), and orWhere() conditions too like andWhere(['read => false]) to show only new messages, such bug would result in showing both read and unread user messages instead of read only. A error yes but not disastrous. But imagine the same thing happening with user scoping condition in an email service or invoicing system you are building, user scoping would be lost and users would see each others' messages or invoices, this would be a disaster.

That's why a top level WHERE condition (e.g. fixedWhere()) not affected by and/or/where() during execution would provide a kind of safe zone or an extra safety layer to avoid such scenarios, making the framework safer in handling such scenarios. Of course fixedWhere() could be used again later during execution but I assume who does that would know what exactly he's doing and why. Furthermore, if the default behavior of fixedWhere() is accumulative (adding conditions instead of replacing them) unless forced to replace via an option as explained above, there still could be bugs but not as disastrous. For example no invoices displayed at all instead of mixing up users' invoices.

Finally, I see where() as a possible problem area as it could wipe out all previous conditions. Of course such function is required but with complex structures and inheritance, I'd prefer if it is handled in a way that makes using it less prone to errors.