Je dois remplacer les méthodes mentionnées ci-dessus pour ignorer certains enregistrements de base de données. Utiliser where n'est pas une option car je devrais l'utiliser à chaque fois car il y a des enregistrements dans la base de données dont je n'ai pas besoin la plupart du temps et je ne suis pas autorisé à les supprimer de DB. Voici ma tentative de faire ceci:
class SomeTable extends BaseModel {
public static function first() {
$query = static::query();
$data = $query->first();
if($data && $data->type == 'migration_type') return null;
return $data;
}
public static function get() {
$query = static::query();
$data = $query->get();
foreach($data as $key => $item) {
if($item->type == 'migration_type') unset($data[$key]);
}
return $data;
}
}
Le problème avec ce code est qu'il ne fonctionne que lorsqu'il est directement appelé sur le modèle. Si j'utilise d'autres fonctions, comme where , avant les méthodes get ou first , cela ignore simplement ma méthode remplacée.
Quelle serait la bonne façon de faire cela et dois-je mettre ce code dans le modèle?
Ma question n'est pas dupliquée car dans la réponse à la question mentionnée, il est dit:
toutes les requêtes faites à partir de Models étendant votre CustomModel recevront ces nouvelles méthodes
Et je dois remplacer ces deux fonctions uniquement pour un modèle spécifique, pas pour chacune d'entre elles dans l'application car toutes les tables n'ont pas de colonne type . C'est la raison pour laquelle je les ai écrits dans la classe modèle.
3 Réponses :
Parce qu'après avoir appelé là où vous traitez avec le générateur de base de données et que ces méthodes à l'intérieur de votre modèle ne sont pas appelées ... à propos du problème, vous pouvez le résoudre en utilisant select au lieu de directement donc traitera avec le constructeur.
exemple:
SomeTable::select('col1','col2')->take(1)->get();
une autre chose qui remplace ce type de méthodes n'est pas une bonne idée si vous travailler avec un autre développeur sur le même projet.
bonne chance
Je travaille avec d'autres développeurs, mais ce n'est qu'un modèle et nous avons tous besoin de ce changement. L'application est trop volumineuse pour changer chaque get pour utiliser select dans sa requête. J'espère qu'il y a un moyen de faire exactement ce dont j'ai besoin
bien sûr, il y a toujours un moyen mon ami .. mais pour garder les choses propres, je suggère de changer le type de ce modèle d'un modèle éloquent en objet sql et d'accepter le générateur de requêtes dans votre classe et d'utiliser la méthode magique __call pour mapper l'appel de get ou first à une méthode personnalisée tout en bénéficiant des avantages du générateur de requêtes
Le problème ici est que la méthode where () sur le modèle renvoie une instance de QueryBuilder où get () renverra une instance de Collection .
Vous devriez être capable de remplacer les méthodes par défaut de la collection en ajoutant une macro à sa place et peut être fait comme ça ...
Collection::macro('toUpper', function () {
return $this->map(function ($value) {
return Str::upper($value);
});
});
L'extension de l'instance du générateur de requêtes n'est pas si facile mais un bon tutoriel existe ici et implique le remplacement de l'application classe de connexion par défaut, ce qui n'est pas génial pour les futures mises à jour.
Je dois remplacer les méthodes mentionnées ci-dessus pour ignorer certains enregistrements de base de données.
Considérez une portée de requête globale sur le modèle.
https://laravel.com/docs/5.8/eloquent#global-scopes
Les étendues globales vous permettent d'ajouter des contraintes à toutes les requêtes pour un modèle donné. La fonctionnalité de suppression logicielle de Laravel utilise des portées globales pour extraire uniquement les modèles "non supprimés" de la base de données. L'écriture de vos propres portées globales peut fournir un moyen pratique et facile de s'assurer que chaque requête pour un modèle donné reçoit certaines contraintes.
@niksrb Une chose à noter: les portées globales ne seront appliquées à aucun appel brut DB :: , car ceux-ci contournent complètement le modèle Eloquent. Si vous utilisez toujours le modèle pour créer des requêtes, tout ira bien.
Copie possible de Laravel 5 - Ignorer Get ou Select from Eloquent
J'ai vérifié celui-ci, mais la réponse n'est pas assez claire
Mon pari est que sur le parent de retour :: where (*****) vous pouvez mettre le vôtre -> où (votre condition à toujours vérifier)
@Djip pouvez-vous l'expliquer un peu plus dans la réponse s'il vous plaît?
Je suppose que c'est là que le modèle de référentiel devient utile.
Ne cherchez-vous pas simplement
$ hidden = 'migration_type'?@piscator Je recherche tous les enregistrements mais
$ hidden = 'migration_type'