Issue posted: https://github.com/laravel/framework/issues/25311
I found an issue on GitHub that raised this. It had been closed by the poster but I through in my two cents. I'm also pinging folks via the #internals slack.
It'd certainly make sense for a special
whereDate() method to wrap the column and the value with
DATE() functions. It's the kinda of magic that Laravel is known for. And it's a trivial implementation detail. And I've run into several other developers (browsing GitHub issues and the Slack) that also assumed it worked that way!
No one is arguing for the framework to babysit my code. But transparently handling a Carbon or DateTime instance in a
whereDate function is pretty intuitive.
->whereRaw('DATE(column_name) = DATE(?)', $value)
That's all I'm asking for. That's not much. ;-)
Looking at the
->toSql() output, it looks like the
$value is just passed in to the where clause directly. The column is wrapped in a
DATE() function, but the value is not. Which to me seems so dangerous because if you pass in a datetime string instead of a date string the where clause will never be true! Which makes me think, what is this helper helping with? It doesn't clean up my code if I have to litter it with
whereDate($column, $value) convert
$value to a date string? I’m passing in a
I’d swear our codebase is covered with code using
`Carb values, but I’ve encountered a query that requires me to
to `$value->toDateStri before passing it into
to `whereDa and I’m baffled (and concerned!).
troygilbert left a reply on Saving An Intervention Image Instance Into Amazon S3
Image::__toSring() method is equivalent to
No, I haven't resolved it. But it did go away. Its been at least weeks since it's happened.
troygilbert started a new conversation My Queue Workers Run Out Of Memory And Die Once Or Twice A Day
Since upgrading to Laravel 5 (5.3.x) (from 4.2), I've noticed that my queue workers (which are daemons) run out of memory and die every 12 hours or so:
Symfony\Component\Debug\Exception\FatalErrorException: Allowed memory size of 134217728 bytes exhausted (tried to allocate 4096 bytes) in /home/forge/example.com/releases/20161020233025/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:91
I've got 8 jobs, all but one are scheduled to happen once per day. The 8th job, which runs every minute, performs a fairly straightforward query of a single table in my MySQL DB (basically looking for expired items). I then execute a simple job for each expired item.
Unless we are pushing test data through the system, this query only returns results once a day, at about 10:30am. The last two memory errors occurred at 11:40am and the previous day at 4:20pm, so they don't appear to be directly correlated with the executing of jobs.
I've double-checked, I don't have DB::enableQueryLog() anywhere, and if I understand correctly, Laravel 5 disables it by default.
I'm kinda at a loss of how to track down a memory leak like this. My jobs and commands don't open any files, or allocate any resources from external libraries, so there's nothing to manually release. The only thing that happens is a single DB query each minute. Feels like that shouldn't leak memory.
Another tidbit of info: I have two queue workers, and they both die with out-of-memory errors. One time they died within 2 seconds of each other, the other time they died 8 minutes apart from each other. (I don't have a preserved log of crashes further back than that.)
I guess it's not really a problem that they run out of memory. The workers crash, supervisor fires them back up, everything keeps going. I'm guessing it'd be more of a problem if it leaked memory then ran out in the middle of an important job instead of just during an idle period.
Thanks in advance for any suggestions.