whereString() / orWhereString()

Type-safe WHERE condition for string values.

Signature

whereString(string $column, mixed $value, string $operator = '='): self
orWhereString(string $column, mixed $value, string $operator = '='): self

Basic usage

Use whereString() to filter by string columns like names, email addresses, status values or slugs. The value is cast to string and bound safely via prepared statement. Non-scalar values like arrays or objects are rejected.

// Step by step
$db->whereString('email', 'alice@example.com');
$user = $db->getOne('users');

// Fluent
$user = $db->whereString('email', 'alice@example.com')->getOne('users');

// → SELECT * FROM users WHERE email = 'alice@example.com' LIMIT 1

With operators

// Step by step
$db->whereString('status', 'active');
$db->whereString('role', 'admin', '!=');
$users = $db->get('users');

// Fluent
$users = $db->whereString('status', 'active')
            ->whereString('role', 'admin', '!=')
            ->get('users');

// → SELECT * FROM users WHERE status = 'active' AND role != 'admin'

Using orWhereString()

// Step by step
$db->whereString('country', 'DE');
$db->orWhereString('country', 'AT');
$db->orWhereString('country', 'CH');
$users = $db->get('users');

// Fluent
$users = $db->whereString('country', 'DE')
            ->orWhereString('country', 'AT')
            ->orWhereString('country', 'CH')
            ->get('users');

// → SELECT * FROM users
//   WHERE country = 'DE' OR country = 'AT' OR country = 'CH'
For filtering by a list of values, whereIn() is more concise: $db->whereIn('country', ['DE', 'AT', 'CH'])

Validation & error handling

Only scalar values are accepted – strings, integers, floats and booleans. Arrays and objects throw an InvalidArgumentException.

try {
    $db->whereString('name', ['Alice', 'Bob']); // ❌ array not allowed
    $users = $db->get('users');
} catch (\InvalidArgumentException $e) {
    echo $e->getMessage();
    // → Non-scalar value given for column 'name'.
}

Security & heuristic check

Even though string values are safely passed via prepared statements, PDOdb adds a heuristic injection check for all WHERE inputs. This protects against classic attack patterns like:

  • '1; SLEEP(1)'
  • 'admin' OR '1'='1'

Whether a suspicious value is allowed or rejected depends on the column type PDOdb detects at query time:

Value Column Type Behavior
'admin@example.com' any ✅ allowed
'admin@example.com OR 1=1' VARCHAR / TEXT ⚠️ suspicious, but allowed
'admin@example.com OR 1=1' INT / DATE ❌ rejected
'1; DROP TABLE users' VARCHAR / TEXT ⚠️ suspicious, allowed with caution
'1; DROP TABLE users' INT / DATE ❌ rejected immediately

If the column is known to be a string field (e.g. VARCHAR, TEXT), the query proceeds as normal. For numeric or date columns, suspicious values are rejected immediately regardless of the method used.

To disable heuristic analysis globally:
define('PDOdb_HEURISTIC_WHERE_CHECK', false);
Only do this if you are absolutely certain your input is already validated elsewhere.

See also

  • whereLike() – pattern matching with wildcards
  • whereIn() – filter by a list of string values
  • whereInt() – type-safe integer filtering
  • where() – generic WHERE without type enforcement