Mark Story
Mark Story
> Both Migration sets should run and all tables should be available in the database as for Plugins the phinxlog is prefixed via audit_stash_phinxlog. How do you have that prefix...
Ok. I will see if I can reproduce this.
I wasn't able to reproduce the problem you're having. I also get different output from `Migrator`. Instead of what you're seeing, I get: ``` Reading migrations status for connection "test"......
Migrations creates a different connection to the database, so you likely have two different databases in play. I don't know how we fix that.
> However, that doesn't work, if open_basedir is set. Would that be a problem for you? I'm not worried about CI environments that can't have `open_basedir` set correctly. > We...
Tagging queries is an interesting idea. Should the tags be an map instead of a list? That would allow us to record metadata about the queries more effectively.
Something like `$query->tags(['type' => 'schema', 'flagged' => true])` this would allow us and userland code to tag/label queries with richer information.
That is pretty confusing. We could start accepting `scale` in the fixtures. But changing the meaning of `precision` in either migrations or fixtures is going to be problematic.
Looks like the `__debugInfo` of Form is returning closure instances. Perhaps we should have Form or the Validator remove the Closure instances out?
I wonder if we should try storing data that isn't the serialized variables. I don't know what that would be, but Debugger::exportVar() might be a good place to start or...