MF-898 - Add bulk connections endpoint

[nwneisen]

Signed-off-by: nwneisen nwneisen@gmail.com

What does this do?

Adds an endpoint to create bulk connections.

Which issue(s) does this PR fix/relate to?

Relates to #898.

List any changes that modify/break current functionality

None

Have you included tests for your changes?

Yes

Did you document any new/modified functionality?

Yes

Notes

[nwneisen]

@manuio I started switching this code over for multiple channels and I realized that I can only have one variadic parameter. I don't see another way besides making the channelIDs parameter a slice but I thought I'd see if you had any ideas before changing everything over.

[manuio]

@nwneisen I'm not sure either... In any case the service endpoint can accept two slices of strings. But for the service method I'm not sure... Maybe a for loop here svc.Connect(ctx, cr.token, cr.ChanID, cr.ThingIDs...); ?
@drasko @nmarcetic what do you think?

[nwneisen]

@manuio I was thinking a for loop would be the way to go without getting caught up in too much optimization. The downside is a for loop on the service method would create multiple transactions; one for each channel. This behavior might not be terrible but I think if one transaction fails then it should be recorded to be returned to the user and the rest allowed to continue.

[nmarcetic]

@nwneisen @manuio IMHO it's OK to have 2 slices, yes can have only 1 variadic param.
@nwneisen For service method you can do the same as you did for things bulk add and do two for loops on repository level :) So you can rollback in a single transaction if something fails.
It's a bit ugly maybe... But it would be hard to accomplish such bulk easy.

Also what if I want to reverse, to connect 100 things to 1 channel? Not 1 thing to 100 channels.
It didn't work like this before, I know, just thinking aloud...

Any ideas @mainflux/maintainers ?

[anovakovic01]

I vote for a single transaction and two slices.

[codecov-io]

Codecov Report

Merging #948 into master will increase coverage by 0.08%.
The diff coverage is 98.64%.

@@            Coverage Diff             @@
##           master     #948      +/-   ##
==========================================
+ Coverage   83.63%   83.71%   +0.08%     
==========================================
  Files          75       75              
  Lines        5248     5288      +40     
==========================================
+ Hits         4389     4427      +38     
- Misses        590      592       +2     
  Partials      269      269

Impacted Files	Coverage Δ
things/redis/streams.go	92.3% <100%> (+0.05%)	⬆️
things/api/things/http/transport.go	94.05% <100%> (+0.28%)	⬆️
things/api/things/http/endpoint.go	98.58% <100%> (+0.04%)	⬆️
things/api/things/http/responses.go	97.75% <100%> (+0.19%)	⬆️
things/service.go	88.97% <100%> (-1.48%)	⬇️
things/api/things/http/requests.go	88.88% <100%> (+1.38%)	⬆️
things/postgres/channels.go	79.84% <94.44%> (+0.07%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update afeec81...4ac942d. Read the comment docs.

[manuio]

LGTM

[drasko]

LGTM

[nmarcetic]

LGTM! Good job @nwneisen