[01:59:20] <Xabster> Hi, I've tried this http://pastebin.com/TbieRMBN - I expected to get a resultset limited to 15 sorted results... and they kind of are that, but everytime i run the query I *can* get different results even though the data is not changed... any ideas?
[03:15:06] <MikeFair> meghan: Hi, kind of amazing that's there's over 300 users, and everyone stays quiet :)
[03:16:40] <meghan> MikeFair: mostly lurkers i suppose!
[03:49:46] <Xabster> Hi, I've tried this http://pastebin.com/TbieRMBN - I expected to get a resultset limited to 15 sorted results... and they kind of are that, but everytime i run the query I *can* get different results even though the data is not changed... any ideas?
[05:23:54] <Xabster> anyone awake now? i asked some hours ago but everyone idled :)
[05:24:03] <Xabster> it's about getting the newest 15 entries in a collection
[05:24:17] <Xabster> i do a sort and then a limit but the results change even though the collection has the same data
[05:28:01] <IAD> Xabster: add "date_created" field into documents and fill it manually, when document be saved
[08:26:43] <JoeyJoeJo> What is the mongo command that will do the same thing as SELECT columnname FROM table?
[08:28:07] <IAD> JoeyJoeJo: you need the list of field in documents of collection?
[08:31:00] <Xabster> is it correct to find(), sort(), and limit() in that order when you want to latest 15 entries? - the sorting is on a timestamp field
[09:00:59] <IAD> documentation: limit() is analogous to the LIMIT statement in MySQL: it specifies a maximum number of results to return. For best performance, use limit() whenever possible. Otherwise, the database may return more objects than are required for processing.
[09:04:24] <cubud> If my db is going to have billions of objects in a single collection would it be worthwhile me using the immutable ID (which is a string) and creating a hash of it, and then using multiple collections MyCollection_{hash}
[09:05:13] <NodeX> sharding the collection would be better
[09:07:51] <cubud> At first I will be using a single server (before there are billions obviously)
[09:08:14] <cubud> Yeah, I think sharding will be better all round, thanks :)
[09:08:44] <cubud> Makes no sense to write a software solution to a problem I currently do not have and that is already solved by the DB :)
[16:35:37] <mikeywaites> hey hoping someone can help, mongo has completely died on my server, its not running and it just falls over everytime i try to restart it. can anyone suggest anything i can try to figure this out?
[16:38:14] <mikeywaites> in the logs im seeing an error about an old lock file]
[16:38:31] <mikeywaites> i have run mongod --repair which i thought would clean that up
[19:17:31] <ppetermann> in an explain() what exactly is indexBounds telling me?
[19:23:29] <ppetermann> i seem todo something horribly wrong, i got a collection with 709068 documents, but an explain on a find shows me 2316051 nscanned, even with an index that should cover all fields, so i seem to be missing something
[19:49:04] <ppetermann> it seems the sort i'm doing is totally killing me, without the sort its all like i expect it, as soon as i add the sort, it goes downhill
[20:09:11] <ppetermann> http://nopaste.info/10117d7bd7.html this one (reverse)
[20:09:14] <kali> ok. this query is not optimizable
[20:09:49] <ppetermann> as i said it seems to be the sort that kills it. withou the sort the or can use two single field indexes and is fast
[20:09:58] <kali> you can either split it in two and have two indexes (attackers.corpId, killTime) and (victim.corpId), one for each query
[20:10:38] <ppetermann> thats not really helping me much, because then i have to resort in the application
[20:10:43] <ppetermann> which makes pagination hell
[20:11:08] <kali> or you need to add an hybrid field (inConflict.corpId) contaning both ids of attackers and victim, then add an index on (inConflict.corpId, killTime)
[20:11:57] <ppetermann> it might be more than one attackers id, but yeah thats the worst-case solution i've come up with aswell, but i was hoping to find a better way
[20:12:24] <kali> if you don't understand why, i strongly advie to loog at the presentation there: http://www.mongodb.org/display/DOCS/Indexes#Indexes-Presentations
[20:17:04] <ppetermann> especially having the names the same as from the api they are comming from enables guys who are shy about touching it (because of mongo) to at least semi-understand whats going on
[20:17:22] <kali> ppetermann: yeah, yeah, i'm aware of the non-technical aspects
[20:17:40] <ppetermann> and since its opensource the understanding of those touching it is quite important
[20:18:46] <ppetermann> i haven't really got why people are so scared of mongo, in most cases its quite simple in use - except if you run into indexing stuff like in this case
[20:18:51] <kali> but anyway, if you want to get this results efficiently, you need a involved: [ corp1, corp2, ... ]
[20:27:52] <ppetermann> honestly with 82 years thats ok
[21:12:01] <Yiq> mongodb is not relational but is it suited for a task where you store blog posts by title and text? or basically if you need mysql or postgres you dont need mongo?