Thanks @ Eric
On 2018-01-10 19:40, "Eric Friedrich (efriedri)" wrote:
> Hi Satheesh-
>
> For now the zip codes are US specific and only allow five digits. If
> you;âd like us to change this, please open a Github issue here:
>
> https://github.com/apache/incubator-trafficcontrol/issues (Cl
I don't think we should assume anything about the performance just
because it uses reflection. Yes, traditionally reflection is
computationally expensive, however, when used properly the penalty can
be negligible. I don't think we have enough understanding of these
libraries to know whether there i
True, but how many of those out-of-the-box checks are both useful and
relevantly complex?
To me, the cool part of ozzo is the way it collects the output and
formats it. That's unfortunately also the computationally expensive
part.
On Thu, Jan 11, 2018 at 9:49 AM, Dewayne Richardson wrote:
> Plea
Please keep in mind that we do not Create/Update/Delete very often in
Traffic Ops, so the performance penalty for Validation should be taken into
consideration. I also don't want to re-invent all of those out-of-the-box
field level checks by hand when I can just use them from here:
https://github.
I like the output style, but I'm a bit concerned on the performance
front. ozzo appears to do all it's magic with heavy use of reflection,
which is often a slow spot in go. Most places, it wouldn't matter
much, but this will be called on every element of every API function,
so a nod toward performa
We've been moving along with more functionality in the Golang proxy, mostly
the Read's up until now, comparatively TO does much fewer Create/Updates.
Our current task is to circle back and start implementing the (C)reate,
(U)pdate, and (D)eletes. One of the obvious needs for the this task are
vali
