7
votes

Capable d'obtenir la collection, mais pas des données filtrées dans la version de production de Slim App à l'aide d'Eloquant

Je travaille sur un Slim 2 et je viens de commencer à déployer sur un serveur de production. Tout semble fonctionner d'accord jusqu'à présent. Je suis capable de me connecter pour que je sache que je me connecte à la base de données tout à fait. Il a reconnu qui je suis connecté comme reconnu quelles autorisations j'ai comme cet utilisateur. J'ai une autre table avec plusieurs entrées. Quand je fais ... xxx pré>

et ... p> xxx pré>

sur le serveur de production, je vois toute la collection comme je faire sur le serveur de développement, mais quand j'ajoute ... p> xxx pré>

et au lieu d'imprimer la collection, essayez d'imprimer le pack comme ... p>

Illuminate\Support\Collection Object ( [items:protected] => Array ( ) )


7 commentaires

Pourrait-il que vous n'ayez aucun objet dans la collection où le statut est 1 en production, mais vous en avez un statut de 1 en développement?


Avez-vous essayé de chaîner la fonction où fonctionne? Par exemple: $ app-> item-> où ('user_id', $ userid) -> où ('statut', 1) -> obtenir (); Et assurez-vous que la base de données a des lignes avec statut = 1.


J'ai vérifié qu'il existe des articles avec un statut de 1 dans la DB de production et dans la collection qui revient. J'ai essayé de chaîner avec succès le lieu où ("statut", 1) lorsque je fais la collection qui fonctionne, mais j'ai aussi besoin de filtrer davantage lorsque l'état = 1 et où l'état = 0 et je ne veux pas frapper la db plus que nécessaire.


Qu'en est-il de l'utilisateur spécifique que vous êtes connecté comme? Y a-t-il des articles avec Statut = 1 pour cet utilisateur en production?


@Quickshiftin Je suis capable de voir la collection pour cet utilisateur, mais pas une collection filtrée faite à partir de celui-là et comme je l'ai dit ci-dessus, quand je chaîne le lieu où elle fonctionne aussi bien.


Dans ce cas, je vous recommanderais de déterminer quelles sont les différences entre vos environnements de production et de développement. Si le code fonctionne comme prévu dans le développement, mais pas la production, quelque chose cause cette différence. Envisager de mettre à jour votre base de données de développement pour répondre à votre base de données de production et essayer de reproduire le problème dans le développement. De là, vous pouvez utiliser un débogueur pour déterminer où réside la différence.


@quickshiftin Je suis capable de tirer la collection de cet utilisateur de la DB dans l'environnement de production et de développement et j'ai vérifié que (à part les dates de création / mise à jour), ils sont identiques. Ma compréhension est que la collection est juste un tableau multidimensionnel et que la collection supplémentaire $ -> où () des filtres sur ce tableau, ne revenant pas à la base de données. Ai-je raison à ce sujet?


3 Réponses :


6
votes

Très probablement, vous n'avez pas d'enregistrement dans la base de données de production avec un statut de 1 et que vous avez des enregistrements avec un statut de 1 dans le développement.

Vérifiez la base de données directement en production pour vérifier.


0 commentaires

2
votes

Apparemment, la collection ne dispose que d'une chaîne ou d'une chaîne seulement ... cela fonctionne!

$pack = $collection->where('status', '1');


3 commentaires

Heureux que vous ayez trouvé une solution, upvote de moi. Je soupçonne que Slim utilise === en interne pour comparer le deuxième argument aux résultats de la base de données au lieu de == . Pourriez-vous découvrir en regardant le code ... Le grand mystère est de savoir comment votre code fonctionne dans Dev mais pas la production sans effectuer la deuxième argument une chaîne.


@QuickShifting ci-dessus Vous avez suggéré de vérifier la structure de la DB. Seule la différence que je pouvais trouver était que la version locale utilisait InnoDb tandis que la télécommande utilisait Myisam. Je ne sais pas si c'était l'origine de la question, mais j'ai changé DEV pour correspondre à la production.


Je parlais des valeurs des enregistrements et non de la structure (schéma) de la DB. Supposé que le schéma serait au moins le même. Essentiellement, lorsque le même code fonctionne dans Dev mais pas prod, il suffit de supprimer les différences pour déterminer où la question réside. N'avez toujours jamais reçu cette question qui a répondu cependant. Pourquoi obtenez-vous des résultats différents dans les deux environnements sans le changement de code?



2
votes

Vérifiez votre version éloquente. Avant 5,3, les collections ont utilisé une comparaison stricte lors de l'utilisation de où () et d'utiliser la libération, vous utilisez whareeloose () mais à partir de 5.3 où () est un comparaison desserré et Wherestrict () est l'appel de méthode strict.


0 commentaires