That would previously result in the worker getting killed with SIGPIPE.
Which works, but we can also recover from that error without restarting
the process.
Because this easily confuses syntax highlighters and some humans with
the q// string syntax. Also for consistency with the 'fu->sql()'
aliases.
The old names are still available as alias.
URI, JSON and formdata decoding no longer checks for control characters,
but FU::Validate now rejects control characters by default. This
decouples semantic validation from format parsing and gives better
control over when control characters are allowed.
Reason for this is that, with FU::SQL, it's possible to accidentally
introduce a bind parameter when a WHERE clause was intended (i.e.
"WHERE $1"). That's pretty bad, but can easily be caught by simply not
accepting *every* possible value as boolean.
I can't think of a use case where Perl's default ref stringification is
something you actually want when writing XML/HTML - this pretty much
always points to a bug. One that I seem to be prone to making...
Apparently 'my sub' captured the $conn variable and held a ref on it
even beyond the parent sub scope. 'my $x = sub {}' doesn't do that.
Getting the ref counts right is important here for the last test to work.
(Found while I was inspecting the refcount effects of the new ->conn()
methods with Devel::Peek)
Turns out VNDB has a few places where request data is directly used for
column names in VALUES/SET/WHERE clauses. These are already restricted
to known strings through the use of FU::Validate, but an extra layer of
protection seems warranted here.
And use it for automatic output compression in FU, as (potentially)
faster alternative to Compress::Raw::Zlib.
Was also planning to maybe add support for Zstd or Brotli, but given the
performance of libdeflate, I'm not sure that's really necessary. Brotli
does tend to do a better job at compressing HTML, though.
I'm breaking stuff left and right while I still can.
Idea: "key_names" validation?
Idea: "tuple" validation that works like "keys" but for arrays.
(i.e. { tuple => { $index => $schema } }, could make "missing" and
"unknown" work for arrays, too)
This allows all built-in options to be duplicated inside a single
schema, the semantics of which are the same as the kind of merging
done as part of inheriting options from custom validations.
This also causes all 'keys' and 'values' validation schemas to be
merged, which changes error messages a bit but is great for
introspection. Probably slightly improves performance as well.
API is not super convenient and implementation is lousy, but uploading
files is not a super common operation so that should be fine.
At least it supports large files with only a single in-memory copy.
Using a consistent numeric interpretation for timestamps, dates and
times simplifies a bunch of operations. It certainly simplifies
conversion between the Postgres formats.
Copied from TUWF::Validate with a few small changes. I have a few more
features planned, but let's see how this goes first.
It's been an incredibly useful module in the past, I'm not sure right
now if I had ideas for potential improvements at some point, will need
to check notes.
And with this, I have a working rewrite of the manned.org backend into
FU. \o/
The $st->row methods are very useful even for queries that may not
return anything, so their old behavior was unhelpful. Interestingly
enough, the error-on-multiple-rows did catch an actual bug in
Manned.org, so I'm keeping that behavior.
...I was hoping not to have to implement the date type, because date
conversions suck, but it turns out manned.org actually needs it.
(Only to then convert it into a Unix timestamp again, hmm, maybe this
string conversion isn't useful at all?)
