Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Predicate fluent methods accept identifier types their predicates reject

Ouverte
  • Quelque chose ne va pas ?
#208 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@simon-mundy y travaille déjà.

Depuis le 5/10/2026.

  • #224 par @simon-mundy — ouverte

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
30/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
php, sql
Domaine
databases

Piste de recherche

Start with the fluent methods in src/Sql/Predicate/Predicate.php and the corresponding constructors in Between.php, Operator.php, In.php, IsNull.php, and Like.php; compare their identifier parameter types. Read docs/book/sql/where-having.md and inspect the predicate tests to find where method signatures are covered. Done means the fluent signatures and API documentation match the constructors, with a test preventing future drift; linked pull request #224 is already open.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug
Package Version

0.6.x-dev @ e022af5c

Php Version

8.3, 8.4, 8.5

Database Engine

Any

Basic Information

The fluent methods on Predicate\Predicate (and so on Where and Having) accept wider identifier types than the predicate classes they build. Each method passes its identifier straight to a constructor that rejects the extra types:

Method Identifier accepted Constructor accepts
between(), notBetween() (Predicate.php#L33) float|int|string|array|ArgumentInterface|null, plus array for min/max Between: string|ArgumentInterface|null (Between.php#L27)
equalTo() and the other comparisons (Predicate.php#L50) float|int|string|ArgumentInterface|null Operator left: string|ArgumentInterface|ExpressionInterface|SqlInterface|null (Operator.php#L50)
in(), notIn() (Predicate.php#L128) float|int|string|ArgumentInterface In: string|ArgumentInterface|null (In.php#L25)
isNull(), isNotNull() (Predicate.php#L160) float|int|string|ArgumentInterface IsNull: string|ArgumentInterface|null (IsNull.php#L22)
like(), notLike() (Predicate.php#L210) float|int|string|ArgumentInterface|null Like: string|ArgumentInterface|null (Like.php#L23)

The leaf constructors were narrowed in #87 (review: "It could simply be string|Argument $identifier = null"); the fluent methods kept the wider types. docs/book/sql/where-having.md documents the wider signatures. It also states that $leftType/$rightType were removed and that a value on the left should be passed as an Argument instance.

Steps to Reproduce
  1. (new Where())->isNull(5)
  2. (new Where())->equalTo(1, 2)
  3. (new Where())->between(['a'], 1, 2)
  4. (new Where())->in(5, [1])
Expected Behavior

Each fluent method accepts exactly what its predicate accepts, so an invalid call fails at the method the caller wrote. A numeric value on the left is passed as new Argument\Value(5), as the docs describe. The API listing in where-having.md should match.

Narrowing does not break working code, because every call it rejects already throws. A test comparing each method's parameter types with its predicate's constructor would stop them drifting apart again.

Actual behavior?
TypeError: PhpDb\Sql\Predicate\IsNull::__construct(): Argument #1 ($identifier) must be of type PhpDb\Sql\ArgumentInterface|string|null, int given
TypeError: PhpDb\Sql\Predicate\Operator::__construct(): Argument #1 ($left) must be of type PhpDb\Sql\ArgumentInterface|PhpDb\Sql\ExpressionInterface|PhpDb\Sql\SqlInterface|string|null, int given
TypeError: PhpDb\Sql\Predicate\Between::__construct(): Argument #1 ($identifier) must be of type PhpDb\Sql\ArgumentInterface|string|null, array given
TypeError: PhpDb\Sql\Predicate\In::__construct(): Argument #1 ($identifier) must be of type PhpDb\Sql\ArgumentInterface|string|null, int given
Additional Info

The unmerged 0.5.x-benchmarking branch restores $leftType/$rightType as a deprecated compatibility layer (75987ac2). If that is ever ported, the left parameter would need to accept a numeric value again, alongside a type.

Langage dominant
PHP
Étoiles
18
Forks
8
Merge moyen
6 j 11 h
PR mergées (30 j)
14

Préparer son environnement

  • Fournit un Dockerfile ou un fichier Docker Compose
  • Aucun modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de php-db/phpdb

Toutes les issues de php-db/phpdb

Issues similaires

Plus d'issues PHP

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.