Log file Viewer

[05:23:23] <scriptonist> how can i write the following snippet in pymonog

[05:23:33] <scriptonist> *pymongo

[05:23:52] <scriptonist> snippet : db.messages.find({$text: {$search: "smart birds who cook"}}, {score: {$meta: "text Score"}}).sort({score:{$meta:"text Score"}})

[05:27:14] <scriptonist> anybody here ?

[07:54:30] <tuskkk___> Hello, while using doctrine, what's the difference in @Field(type="string") vs @ODM\Field(type="string")?

[08:05:31] <joannac> tuskkk___: try one of the Doctrine support avenues?

[08:54:17] <Zelest> i feel retarded.. i don't get $in :(

[08:54:51] <Zelest> {field: {$in: ['some', 'fancy', 'array']}}

[08:54:55] <Zelest> but what if field is an array?

[08:55:05] <Zelest> and I want to see if "some" exists in that array

[08:58:36] <Zelest> oh, just skip $in altogether..

[08:58:42] <Zelest> nvm me.. havn't had my coffee yet

[11:30:12] <alexi5> good morning everyone

[15:30:14] <TimoRuetten> Hey, MongoDB Geeks. Maybe some of you are able to help me out with a performance issue when using $near in MongoDB 2.6.10 ? I hope its okay to reference here to an stackoverflow issue.

[15:30:22] <TimoRuetten> You can find the issue here: http://stackoverflow.com/questions/39126419/mongodb-near-operation-very-slow-and-causes-timeouts-even-with-indexing

[15:46:39] <StephenLynx> I don't think that version is supported anymore.

[15:47:40] <StephenLynx> also,

[15:47:51] <StephenLynx> i'd argue that your objects are way too nested.

[15:49:35] <cheeser> 2.6 is, sure.

[15:49:55] <cheeser> 2.4 is still supported, even, but i don't think it's getting any updaets

[15:49:55] <StephenLynx> but 2.6.10?

[15:50:00] <cheeser> why not?

[15:50:08] <StephenLynx> isn't the latest release 2.6.12?

[15:50:50] <cheeser> that i don't know. havne't looked.

[15:51:01] <cheeser> but that wouldn't mean .10 is desupported

[15:51:31] <StephenLynx> if it has any issues that were fixed on either 0.11 or .12 what happens?

[15:51:37] <StephenLynx> you release 2.6.10.1?

[15:52:15] <Derick> 20.6.13

[15:52:18] <Derick> 2.6.13

[15:52:46] <StephenLynx> but the issue has been already fixed.

[15:53:13] <StephenLynx> on the same version.

[15:53:54] <TimoRuetten> Yes the document is nested - but in our case we think this nested object should be as it is

[15:54:24] <StephenLynx> you could think 1 + 1 = 3, it doesn't mean its right.

[15:54:40] <TimoRuetten> Do you think it would be good to add a non nested property to our document where our GeoJSON is in ?

[15:54:59] <TimoRuetten> Additional to our nested

[15:55:08] <StephenLynx> I would try to find a way to not nest as deep as it is.

[15:55:25] <StephenLynx> I don't know your use case to give an exact way to achieve that.

[15:55:36] <TimoRuetten> Thats a good information - so when we do a query not to do as deep as it is now. But do you also think this causes our problem ?

[15:55:52] <StephenLynx> It might.

[15:56:02] <StephenLynx> but I am not 100% sure.

[15:56:27] <StephenLynx> I have a guess that the more you nest, the less efficiently you can use indexes.

[15:57:21] <StephenLynx> I'd also try updating to see if performance improves.

[15:57:33] <StephenLynx> 2.6 is ancient by no.

[15:57:35] <StephenLynx> now*

[15:57:51] <TimoRuetten> Okay. Thanks for the first hint. I will change the schema we use currently and move the geojson to the first level and rerun the query

[15:58:34] <StephenLynx> i'd also use explain to see if it provides any useful information.

[15:58:45] <StephenLynx> and how many documents you have?

[15:59:15] <TimoRuetten> currently around 2.000.000

[19:09:21] <n1colas> Hello