This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[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> 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> 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>

[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: ?

[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