Differences

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

Link to this comparison view

irc:1440540000 [2017/05/27 13:44] (current)
Line 1: Line 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>​ 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