fix: Scope orWhere clauses in Item::exists() and Item::get_item_id() (#4520)

In PR #4250 (commit 29c3c55), orWhere was added to match items by
either item_id or item_number, but the OR condition was not wrapped
in groupStart()/groupEnd(). This causes:

1. Wrong SQL semantics: generates
   WHERE item_id = ? OR item_number = ? AND deleted = 0
   instead of
   WHERE (item_id = ? OR item_number = ?) AND deleted = 0
   Due to AND binding tighter than OR, the deleted filter only applies
   to the item_number branch, allowing deleted items to match via item_id.

2. Performance: the unscoped OR causes MySQL to bypass the item_id
   primary key index and fall back to full table scans when item_number
   is a string column compared against a numeric parameter.

Both exists() and get_item_id() are fixed by wrapping the OR
conditions in groupStart()/groupEnd() for proper parenthesization.

Co-authored-by: Ollama <ollama@steganos.dev>
This commit is contained in:
jekkos
2026-04-20 06:22:42 +00:00
committed by GitHub
parent 0a313aa09d
commit e602eddb47

View File

@@ -65,8 +65,10 @@ class Item extends Model
public function exists(string $item_id, bool $ignore_deleted = false, bool $deleted = false): bool
{
$builder = $this->db->table('items');
$builder->groupStart();
$builder->where('item_id', $item_id);
$builder->orWhere('item_number', $item_id);
$builder->groupEnd();
if (!$ignore_deleted) {
$builder->where('deleted', $deleted);
@@ -390,8 +392,10 @@ class Item extends Model
{
$builder = $this->db->table('items');
$builder->join('suppliers', 'suppliers.person_id = items.supplier_id', 'left');
$builder->groupStart();
$builder->where('item_number', $item_number);
$builder->orWhere('item_id', $item_number);
$builder->groupEnd();
if (!$ignore_deleted) {
$builder->where('items.deleted', $deleted);