Re: Traffic Ops Rewrite Golang Dependency - sqlx

The deadline of Friday 09-15 at noon has passed, sqlx as a TO Golang Dependency has been accepted. The vote tally is 6 Aye to 2 Nay's Have a good weekend, -Dew Results: Dan Kirkwood: +1 Derek Gelina: +1 Dewayne Richardson: +1 Dylan Volz: +1 Jan Van Doorn: +1 Jeremy Mitchell: +1 Chris Lemmons:

Re: Traffic Ops Rewrite Golang Dependency - sqlx

I see, just looked at SliceScan, I mistakenly assumed it was how they implement selecting into a slice of structs which is one of the features that is very useful versus the straight sql implementation. On 9/13/17, 9:59 AM, "Chris Lemmons" wrote: That's not the problem

Re: Traffic Ops Rewrite Golang Dependency - sqlx

That's not the problem that SliceScan helps with. SliceScan helps when you don't have control of the sql statement and you don't know the columns that will be returned, or how many will be returned. MapScan does the same, but puts it into a map, so you can iterate over them. That's a major feature

Re: Traffic Ops Rewrite Golang Dependency - sqlx

Yes Select, or the SliceScan is one of the reasons I would use sqlx, I am pulling out sets using IN and left outer joins to avoid the tight looping issues in some endpoints in the perl. On 9/13/17, 8:42 AM, "Chris Lemmons" wrote: I see that there's a significant

Re: Traffic Ops Rewrite Golang Dependency - sqlx

I see that there's a significant preference to not list the members of the struct in the Scan function. That works. I'm still not certain I understand why we'd prefer to bring in all of `sqlx` instead of writing a single, fairly simple function to return the columns for the scan. Are there plans

Re: Traffic Ops Rewrite Golang Dependency - sqlx

I also agree but I think your argument about future cost is more "speculative" than reality. If we're smart about how we integrate sqlx, then we can hedge the bet. -Dew On Tue, Sep 12, 2017 at 7:52 PM, Robert Butts wrote: > I am a pretty big -1 on sqlx. Those PRs are

Re: Traffic Ops Rewrite Golang Dependency - sqlx

I'm also not 100% on sqlx 100% of the time, but what I'm 100% on is ease of use, development productivity, and minimizing bug introduction. -Dew On Tue, Sep 12, 2017 at 9:08 PM, Chris Lemmons wrote: > @dan, how do you feel about the middle-ground I proposed: a >

Re: Traffic Ops Rewrite Golang Dependency - sqlx

As one ready to jump in and add more endpoints, I'm a strong +1 on using sqlx. I agree that adding a new dependency should not be done without consideration, but I find the sqlx version much more readable and easier to approach than either your or dew's version of non-sqlx and would be much

Re: Traffic Ops Rewrite Golang Dependency - sqlx

> Why the fear of using dependencies? There's no fear of using dependencies. There's a recognition that dependencies aren't free and a balancing of the costs they entail. In this case, looking at the costs associate with `sqlx`, I don't think the benefits justify it. The way we're using it, we

Re: Traffic Ops Rewrite Golang Dependency - sqlx

@dewayne - you said "performance was +/-5% depending on the cloud resources that were active". How many milliseconds difference (average) are we talking about for ONE call to /api/1.2/servers (using sqlx and not using sqlx)? I'm assuming it is so small that we can rule out performance as a factor

Re: Traffic Ops Rewrite Golang Dependency - sqlx

I am a pretty big -1 on sqlx. Those PRs are extremely deceptive. Those lines are entirely unnecessary. I have created an example PR at https://github.com/apache/incu bator-trafficcontrol/pull/1165 The relevant commits are https://github.com/apache/incubator-trafficcontrol/pull/1165

Re: Traffic Ops Rewrite Golang Dependency - sqlx

After looking at the code, and given the work I've been doing with rewriting the config file endpoints, I have to say sqlx all the way. What's involved in the maintenance? Derek On Sep 12, 2017, at 8:28 PM, Dewayne Richardson > wrote: There has