Differences

This shows you the differences between two versions of the page.

Link to this comparison view

irc:1452639600 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[17:35:38] <​skeet70>​ If I have a Verticle that takes in a parameter and needs to do some DB work before responding with the result of a call to another Verticle, what is the preferred pattern in Vertx? Right now I'm doing a send and trying to return the result (a CompletableFuture<​JsonArray>​). I've tried a few other things along the way, but it feels like I'm fighting against the framework.
 +
 +[17:38:45] <​temporal_>​ you want to turn 2 results into a combined result ?
 +
 +[17:40:12] <​skeet70>​ Yeah, essentially. I'm not sure if I'm calling/​getting the second result correctly with send though.
 +
 +[20:02:53] <​edcaceres>​ Hi, is there any plan to add support for clojure? (Vertx 3)
 +
 +[21:05:40] <​temporal_>​ edcaceres there are no plans however we I would love and fully support this :-)
 +
 +[21:05:48] <​temporal_>​ (meaning that if I had time I would do it myself but I can't)
 +
 +[21:07:58] <​edcaceres>​ :( would be great
 +
 +[21:48:50] <​temporal_>​ skeet70 it is a concern that arise often , I'm working to see if we can find a simple solution to this
 +
 +[22:01:35] *** ChanServ sets mode: +o temporalfox
 +
 +[22:19:25] <​skeet70>​ @temporalfox,​ fyi I'm wrapping everything in CompletableFutures all over the place and using combine to do something with both return values. It certainly gets more awkward with more than two futures.
 +
 +[22:19:55] <​temporalfox>​ skeet70 in this case it would use io.vertx.core.Future so it is polyglot
 +
 +[22:20:16] <​temporalfox>​ and it would allow to transform a io.vertx.core.Future as an Handler<​AsyncResult>>​
 +
 +[22:20:29] <​temporalfox>​ so one can create a Future and pass its handler to a callback
 +
 +[22:20:48] <​temporalfox>​ then take a couple of Future and combine them into a new Future
 +
 +[22:21:01] <​temporalfox>​ then this future can be set an handler to be notified of the result
 +
 +[22:21:08] <​temporalfox>​ more or less like
 +
 +[22:21:23] <​temporalfox>​ Future<​String>​ f1 = Future.future();​
 +
 +[22:21:24] <​temporalfox>​ Future<​String>​ f2 = Future.future();​
 +
 +[22:21:35] <​temporalfox>​ asyncMethod1(f1.handler());​
 +
 +[22:21:41] <​temporalfox>​ asyncMethod2(f2.handler());​
 +
 +[22:22:08] <​temporalfox>​ CompositeFuture composite = Future.and(f1,​ f2);
 +
 +[22:22:26] <​temporalfox>​ composite.setHandler(result -> ... );
 +
 +[22:23:18] <​skeet70>​ CompositeFuture f1 = foo()
 +
 +[22:24:07] <​skeet70>​ f1.thenCombine(f2,​ this::​functionThatCaresAboutBoth)
 +
 +[22:24:27] <​temporalfox>​ or maybe simpler
 +
 +[22:24:48] <​temporalfox>​ CompositeFuture future = CompositeFuture.and(2);​
 +
 +[22:25:00] <​temporalfox>​ then do future.get(0) returns a Future
 +
 +[22:25:37] <​jtruelove_>​ just my 2 cents, i do things like this in vertx-util with a promises impl i put together
 +
 +[22:25:53] <​temporalfox>​ can you show me ?
 +
 +[22:25:59] <​skeet70>​ We're already kinda outside of normal vertx flows it seems, since 1) we didn't find those flows very well defined/​disagreed with them in several places, and 2) because of that we're operating several levels of abstraction away from core vertx stuff, which generally makes things nicer for us.
 +
 +[22:26:48] <​skeet70>​ In this instance though it definitely complicated things a bit.
 +
 +[22:26:50] <​skeet70>​ :D
 +
 +[23:38:51] *** ChanServ sets mode: +o temporalfox
 +
 +[23:54:18] *** ChanServ sets mode: +o temporalfox