[03:11:49] * ChanServ sets mode: +o temporalfox [08:35:09] * ChanServ sets mode: +o purplefox
[09:14:56] <amr> how do you query by _id in vertx-mongo-client?
[09:15:13] <amr> json objects cant take objectids as vals, and string values dont seem to work
[09:34:17] <amr> hm, from the code it _looks_ like it should get wrapped and converted
[12:31:01] * ChanServ sets mode: +o purplefox [12:32:38] <Sticky> amr: I dont think you can [12:33:52] <Sticky> looking at it the JsonObjectCodec does not encode _id to ObjectId's when converting a JsonObject to Bson via the writeDocument method [12:34:04] <Sticky> so it just treats _id as a string [12:38:29] <Sticky> https://github.com/vert-x3/vertx-mongo-client/blob/94f21c29e7d701281f50f5b488db63c47c825f29/vertx-mongo-client/src/main/java/io/vertx/ext/mongo/impl/codec/json/JsonObjectCodec.java#L97 I think that line rather than just writing the values into the consumer needs to convert them to Bson first, otherwise it will be impossible to query by any non-primative type [12:57:18] <Sticky> amr: actually further on that, if the object was created via the client then it will have a String as an _id anyway, so the normal lookup should work, but if its created outside it will have an ObjectId and you are screwed [13:12:55] * ChanServ sets mode: +o purplefox
[13:54:12] <amr> sticky: wow, that's dumb.
[13:59:13] <amr> kinda gives the finger to literally anything else that uses mongo's default behaviour
[13:59:39] <Sticky> It was the same for a long time for the vertx 2 persistor too
[14:00:00] <amr> never used it, im moderately new to using mongo with vertx
[14:00:55] <Sticky> https://github.com/vert-x3/vertx-mongo-client/pull/35 fixes using object ids, however from my brief reading of the patch does not support object id's on the _id field
[14:01:14] <amr> haha
[14:01:18] <amr> the one place you expect them
[14:02:27] <amr> i wonder if i can use something like $binary
[14:02:57] <Sticky> no
[14:03:01] <amr> youre supposed to use the mongoclient directly in your verticle, right?
[14:03:14] <Sticky> that patch adds $binary support too
[14:03:45] <Sticky> https://github.com/vert-x3/vertx-mongo-client/blob/94f21c29e7d701281f50f5b488db63c47c825f29/vertx-mongo-client/src/main/java/io/vertx/ext/mongo/impl/codec/json/JsonObjectCodec.java#L126
[14:03:57] <Sticky> you can see there what is and is not supported
[14:04:16] <amr> ah
[14:04:55] <amr> hm, i guess i better switch to another mongo client
[14:05:00] <amr> at least for this project
[14:05:08] <amr> ive got no way to change the way data is inserted
[14:05:17] <Sticky> our solution to most of this is not to use mongo types
[14:05:28] <Sticky> except for objectids
[14:05:43] <amr> objectids that arent in _id
[14:05:50] <Sticky> yeah they are
[14:06:10] <Sticky> by default mongo generates an ObjectId for an _id
[14:06:15] <amr> surely you cant be using the new mongoclient then, otherwise youd hit the problem i hit?
[14:06:39] <Sticky> oh, I am porting from vertx 2 (where this worked) to 3 at the moment
[14:06:45] <amr> ah
[14:06:47] <Sticky> and no, have not hit this yet
[14:06:56] <Sticky> we will probably have to patch it
[14:07:25] <amr> give me a heads up if/when you do
[14:07:40] <Sticky> sure
[14:09:41] <amr> actually, can you make mongoclient create instances of classess youve pepper with some jackson annotations?
[14:09:47] <amr> instead of jsonobjects?
[14:09:58] <amr> i expect not
[14:23:21] <purplefox> Sticky: even better if you guys were maintainers of the V3 mongo client like you were in V2 :)
[14:26:41] <amr> who are “you guys” ?
[14:41:05] <Sticky> purplefox: yeah, martijn has been hasling me to give you an answer on if we will help maintain it
[14:41:22] <Sticky> think I have descided to go with yes
[14:50:50] <purplefox> Sticky: that would be awesome :)
[14:51:09] <purplefox> the more stuff we can get out the larger community the better
[14:52:22] <Sticky> sure
[14:59:21] <purplefox> Sticky: if you haven't seen already can you take a look at: https://github.com/vert-x3/wiki/wiki/Vert.x-3-Official-stack-and-component-maintainers ?
[15:00:01] <purplefox> Sticky: if you're happy I can announce you as official maintainer on the list
[15:00:35] <purplefox> i'd need to propose you and others vote, but should be pretty straightforward
[15:11:18] <Sticky> ok ill have a read
[15:12:12] <Sticky> probably get martijn to go too, hes always good at helping
[15:17:15] <purplefox> cool, you can do joint maintainership if you like
[17:04:08] <melvinross> when adding routes to a router, is there anything that stops you from adding functionally equivalent route objects to a router?
[17:06:09] <melvinross> by which i mean, same route criteria, handlers, etc
[17:06:16] <melvinross> not just same path for example
[17:10:20] <Sticky> do you mean you want to make your own route matching predicate?
[17:11:30] <Sticky> no, probably not…not sure what you mean
[17:13:49] <melvinross> I currently have a vertical which handles http request and forwards their contents to other vertices depending on the route
[17:14:12] <melvinross> currently, those other verticles are using the event loop to register what routes they'd like to be notified of
[17:15:01] <melvinross> so when multiple listener vertices start, they all essentially try to re-register themselves
[17:15:41] <melvinross> before writing code to check this, i was wondering how vert internally handled passing to route objects to router that are different objects but are internally identical
[17:15:56] <melvinross> i assumed it would just accept them both, and essentialy handle that route twice
[17:16:11] <melvinross> but I figured I'd ask