Résumé des erreurs courantes et des solutions dans Laravel

1. Erreur : "Impossible d'échanger l'instance PDO pendant la transaction"

En interrogeant le code source de Laravel, vous pouvez confirmer que l'exception a été levée dans la méthode setPdo :

<?php
 
public function setPdo($pdo)
{
  if ($this->transactions >= 1) {
    throw new RuntimeException("
      Can&#39;t swap PDO instance while within transaction.
    ");
  }
 
  $this->pdo = $pdo;
 
  return $this;
}
 
?>

Littéralement comprise, cette erreur se produit car la connexion à la base de données est commutée alors que la transaction est activée. Cependant, cette erreur peut parfois se produire même si la connexion à la base de données n'est pas explicitement commutée dans le code. Par exemple, lorsqu'une erreur se produit lors de l'exécution d'une instruction de requête, le système utilisera la méthode tryAgainIfCausedByLostConnection pour déterminer si le problème est dû à une perte de connexion. Si tel est le cas, le système se reconnectera via la méthode de reconnexion. effectuez certaines opérations via la méthode de déconnexion, dans laquelle la méthode setPdo est appelée.

Après avoir trié la cause et l'effet, vous saurez naturellement comment résoudre le problème : vérifiez la situation du réseau et confirmez la raison pour laquelle la connexion à la base de données est perdue. Cela peut être un problème avec un certain. périphérique, ou il peut s'agir d'un réglage incorrect d'un délai d'attente causé par. Une solution relativement sale consiste à exécuter la méthode DB::reconnect() pour se reconnecter à la base de données avant d'interroger.

2. Erreur : "Impossible de supprimer le travail : NOT_FOUND"

Ce problème n'a en réalité rien à voir avec Laravel, mais est causé par le service de file d'attente Beanstalk.

Pour résoudre ce problème, vous devez d'abord comprendre le cycle de vie d'un message : lorsqu'un message est mis dans la file d'attente, il entre en même temps dans l'état PRÊT. time, Il sera associé à une minuterie TTR (time to run), indiquant l'heure à laquelle ce message est autorisé à s'exécuter. Lorsque ce message est consommé, il entre dans l'état RÉSERVÉ. Après consommation, le message sera supprimé. time S'il est trop long, plus long que TTR, alors le système considérera que le consommateur a raccroché, renverra le message de l'état RÉSERVÉ à l'état PRÊT et le remettra à un autre consommateur pour retraitement. Par conséquent, le même message peut être traité par plusieurs consommateurs. Le premier consommateur à terminer le traitement peut supprimer le message normalement, tandis que les consommateurs restants signaleront une erreur qui ne peut pas être supprimée lors de la suppression du message.

La solution est très simple. Premièrement, vous devez vous assurer que le paramètre TTR ne peut pas être trop petit. Deuxièmement, Beanstalk fournit en fait une commande tactile spéciale pour résoudre le problème du temps d'exécution trop long. De plus, nous pouvons parfois avoir besoin de verrouiller au niveau de l'application pour éviter que le même message ne soit traité par plusieurs consommateurs en même temps.

3. Erreur : "Aucun résultat de requête pour le modèle"

Lorsque la séparation lecture-écriture Laravel est activée, les consommateurs peuvent recevoir des erreurs similaires lors du traitement des messages. Une commande de file d'attente potentiellement problématique ressemble probablement à ceci :

<?php
 
class Foo extends Command implements SelfHandling, ShouldBeQueued
{
  use InteractsWithQueue, SerializesModels;
 
  protected $bar;
 
  public function __construct($id)
  {
    $this->bar = Bar::find($id);
  }
 
  public function handle()
  {
    // $this->bar
  }
}
 
?>

Évidemment, lorsque la séparation lecture-écriture Laravel est activée, find peut ne pas être en mesure d'interroger les données correspondantes en raison du délai maître-esclave, une fois. Si nous analysons cela, nous modifierons probablement l'écriture comme suit :

<?php
 
class Foo extends Command implements SelfHandling, ShouldBeQueued
{
  use InteractsWithQueue, SerializesModels;
 
  protected $bar;
 
  public function __construct($id)
  {
    $this->bar = Bar::onWriteConnection()->find($id);
  }
 
  public function handle()
  {
    // $this->bar
  }
}
 
?>

En d'autres termes, la requête est corrigée sur le serveur principal via la méthode onWriteConnection de Laravel, mais elle est en réalité invalide. Le nœud du problème est que lors de la désérialisation, le système appellera findOrFail une fois depuis le serveur.

<?php
 
protected function getRestoredPropertyValue($value)
{
  return $value instanceof ModelIdentifier
    ? (new $value->class)->findOrFail($value->id) : $value;
}
 
?>

Parce que nous ne pouvons pas pirater le framework, onWriteConnection n'a aucun sens. En fait, en regardant le problème sous un autre angle, assurez-vous simplement de ne pas utiliser d'objets de base de données comme attributs lors de la sérialisation :

<?php
 
class Foo extends Command implements SelfHandling, ShouldBeQueued
{
  use InteractsWithQueue, SerializesModels;
 
  protected $id;
 
  public function __construct($id)
  {
    $this->id = $id;
  }
 
  public function handle()
  {
    $bar = Bar::onWriteConnection()->find($this->id);
  }
}
 
?>

4. Résumé

Ce qui précède est ce que j'ai rencontré lors de l'utilisation Laravel Plusieurs rapports d'erreurs et solutions représentatifs. Si vous avez des questions, veuillez les partager. J'espère que cet article pourra être utile aux études ou au travail de chacun.

Pour plus d'articles sur les erreurs courantes et les solutions dans Laravel, veuillez faire attention au site Web PHP chinois !