PMXBOT Log file Viewer

Help | Karma | Search:

#mongodb logs for Wednesday the 29th of August, 2012

(Back to #mongodb overview) (Back to channel listing) (Animate logs)
[00:24:12] <daniel____> hi, every body. i'm newbie for mongo. and i wanna learn something here with you. thanks
[01:07:27] <daniel____> 有人在吗
[02:12:57] <Aleross> daniel: ni hao!
[02:51:41] <macBigRig> need help with indexing and syntax, see http://pastie.org/4607825
[02:57:05] <crudson> macBigRig: use dot notation to index nested attributes, but note that you will get entire documents back, not just the bit of the array that matches, unless you do some extra work (depends what you really want to do). The second question is simple enough with .aggregate()
[02:59:38] <macBigRig> curdson, looking for syntax examples for indexing. As for selecting, what kind of extra work is needed to get that output. Again any example is greatly appreciated.
[03:05:45] <crudson> macBigRig: e.g. ensureIndex({'PS.RRB':1})
[03:12:28] <crudson> macBigRig: this will give you an array of items that fits your second Q: db.c.aggregate({$unwind:'$PS'}, {$project:{CR:1,'PS.ETB':1,'PS.DRB.HIC':1,'PS.PTB':1}}, {$unwind:'$PS.PTB'})
[03:13:01] <crudson> filter out the unrequired 'PS.PTB.PCC' and PLC as desired
[03:20:50] <crudson> macBigRig: specifically for your output: http://pastie.org/4607928
[03:46:59] <hadees> how terrible is it to use a string as the _id ? I'm creating a versioning system for my collection and so I want the history table to have the _id: <objectid>:<version>
[04:02:20] <crudson> hadees: Not terrible at all. "If your document has a natural primary key that is immutable we recommend you use that in _id instead of the automatically generated ids." source: http://www.mongodb.org/display/DOCS/Object+IDs
[04:16:48] <tyl0r> Is it worth adding an arbiter to a 3 node replica set? Does that mean if 2 servers go down (for whatever unlikely reason), the 3rd will be elected to be the Master for writes?
[07:30:52] <[AD]Turbo> hola
[07:40:52] <jsmonkey123> If I have a collection called Foo and that collection stores multiply documents that has a property called boo that has an array with strings. If I want to remove one of the strings. Is the proper method to use update? or is it remove and specify what property/entity to remove?
[07:41:15] <NodeX> you can $pull
[07:41:48] <NodeX> http://www.mongodb.org/display/DOCS/Updating#Updating-%24pull <---
[07:43:15] <jsmonkey123> NodeX: thanks!
[08:54:12] <makka> I'm having trouble debugging a mapreduce - is this the right syntax for launching a mapreduce from the shell with a subset of documents in the collection (those with foo == bar) : "db.coll.mapReduce(map, reduce, {out:"test"}, {query: { "foo" : "bar" })"
[09:07:05] <rantav> Hi, I need help with performance problems, anyone on board?
[09:07:20] <rantav> I just posted my question to the forum https://groups.google.com/forum/?fromgroups=#!topic/mongodb-user/NClTihy_PPk
[09:07:33] <rantav> But I figured that might be easier to do this over IRC...
[09:07:55] <rantav> I'm seeing VERY slow queries
[09:08:04] <rantav> but the queries are on index
[09:08:19] <rantav> so I can't figure out when they are so slow or how to make things better...
[09:08:48] <rantav> ok, if anyone's in the room that can help I'll post more detains here… LMK...
[09:09:19] <NodeX> what does mongostat report?
[09:10:13] <NodeX> range queries have to be the last part of the index iirc
[09:10:48] <rantav> Let me post mongostat, 1 sec
[09:11:00] <NodeX> it's your index
[09:11:09] <NodeX> the range MUST be the last part of it
[09:11:17] <NodeX> it's not using it efficiently
[09:11:54] <rantav> oh, sorry, @NodeX, were you referring your question to me?
[09:13:04] <NodeX> Yes
[09:13:52] <rantav> mongostat during my query:
[09:13:55] <rantav> insert query update delete getmore command flushes mapped vsize res faults locked % idx miss % qr|qw ar|aw netIn netOut conn time
[09:13:55] <rantav> 6 2 170 0 2 199 0 13.9g 28.5g 979m 8 36.4 0 0|7 2|7 1m 1m 125 09:08:59
[09:13:57] <rantav> 5 0 143 0 0 175 0 13.9g 28.5g 1.08g 15 8.5 0 0|0 2|0 1m 23k 125 09:09:00
[09:13:58] <rantav> 3 2 60 0 0 73 0 13.9g 28.5g 1.17g 20 1.6 0 0|0 1|0 57k 4m 125 09:09:01
[09:14:00] <rantav> 0 0 0 0 0 1 0 13.9g 28.5g 1.24g 13 0 0 0|0 1|0 62b 1k 125 09:09:02
[09:14:01] <rantav> 2 4 68 0 0 85 0 13.9g 28.5g 1.28g 5 2 0 2|0 5|0 94k 27k 125 09:09:03
[09:14:03] <rantav> 0 0 0 0 1 1 0 13.9g 28.5g 1.06g 8 20.2 0 0|0 1|0 966b 208k 125 09:09:04
[09:14:04] <rantav> 0 0 0 0 0 1 0 13.9g 28.5g 1.12g 12 0 0 0|0 1|0 62b 1k 125 09:09:05
[09:14:06] <rantav> 4 4 38 0 0 50 0 13.9g 28.5g 1.14g 13 5.1 0 0|0 3|0 25k 7k 125 09:09:06
[09:14:07] <rantav> 0 2 14 0 0 20 0 13.9g 28.5g 1.23g 3 0.4 0 0|0 2|0 11k 260k 125 09:09:07
[09:14:08] <rantav> 0 0 7 0 0 9 0 13.9g 28.5g 1.29g 16 0.2 0 0|0 1|0 5k 13k 125 09:09:08
[09:14:12] <rantav> these are 10 seconds, sometime after the query started running
[09:14:54] <rantav> The overall query time was 87000 millis, so the mongostat doesn't cover the entire query lifetime
[09:15:08] <Gargoyle> Morning all!
[09:16:28] <Gargoyle> Should I be worried about a possible memory leak message in the log file?
[09:18:32] <NodeX> use a pastebin rantav
[09:18:45] <NodeX> and again. Change your index to reflect RANGE at the end
[09:19:16] <rantav> NodeX yeah sorry, I'll use pastebin next time
[09:19:36] <rantav> anyway, I will change the index such that the range is last
[09:19:45] <rantav> however, that doesn't explain everything
[09:19:58] <Gargoyle> Eg. Wed Aug 29 11:17:17 [conn35034] warning: virtual size (82655MB) - mapped size (78108MB) is large (4265MB). could indicate a memory leak
[09:20:10] <rantav> b/w I have another query, in which the index does have ranges last, and it's still awefully slow
[09:20:25] <rantav> I'll put it in pastebin and post it here in a minute
[09:23:20] <NodeX> you changed the index on 1.8 million documents already ? .... I would imagine the index is still building
[09:28:03] <rantav> Here's the pastebin with one of my slow queries http://pastebin.com/PjxtQMG8
[09:28:13] <rantav> NodeX, I have not changed the index yet
[09:28:37] <rantav> and in this pastebin you can see that the ranges are last on the index (It's a bit different query)
[09:30:05] <NodeX> one problem at a time
[09:30:36] <NodeX> Look at the index bounds - it's true to An IDODate ...
[09:30:46] <NodeX> (on the start)
[09:30:57] <NodeX> Scratch that
[09:31:30] <NodeX> can you swap the end_start around?
[09:31:45] <rantav> NodeX in the query?
[09:31:52] <rantav> sure, let me give this a try
[09:34:44] <rantav> NodeX I swapped end/start dates in the query, no good, still slow :( took 75 secs this time
[09:35:19] <NodeX> are your indexes in RAM or spilling to disk?
[09:37:05] <rantav> right, that's what I was about to check
[09:37:09] <rantav> how do I do that?
[09:37:12] <rantav> I'll read...
[09:44:46] <kali> rantav: don't worry about the weird value for the isodate, i've seen that before, it's how the shell show the "max value" for a date
[09:45:49] <rantav> NodeX, if I'm right, the indexes do fit into ram http://pastebin.com/LpJzdsY7
[09:45:56] <rantav> kali thanks
[09:46:45] <rantav> But is there a way to sum up all indexes sizes from all collections? Not just index size of a single collection?
[09:47:01] <NodeX> db.stats() iirc
[09:48:00] <rantav> nodex thanks, so index does fit into memory, for all collections
[09:50:12] <kali> rantav: this query is hard to make efficient, you have two range in it
[09:50:21] <kali> rantav: worse than that, two half ranges
[09:50:31] <rantav> kali - half?
[09:51:03] <kali> rantav: yes, half a range on start, half a range on end
[09:51:10] <rantav> oh, I see what you mean by half...
[09:51:45] <rantav> ok, so I ran another query with just "start" and no "end"
[09:51:51] <rantav> and it was much faster
[09:52:03] <rantav> but still takes about 6 seconds
[09:52:31] <kali> rantav: want to show the explain ?
[09:52:32] <rantav> although this time it might make sense, b/c it's not fully indexed (there's no index for just serviceId+start)
[09:52:43] <rantav> kali, yeah, 1sec
[09:53:15] <kali> your index should be fine for queries with a service value + a range (or a half-range) on start
[09:53:56] <rantav> kali, here's the explain for a query with only one half-range http://pastebin.com/9zZ3Vb0x
[09:55:24] <rantav> kali, I can modify my query to use two full-ranges
[09:55:30] <rantav> do you think it'll make it better?
[09:55:38] <kali> i would have expected the number of nscanned to be the same...
[09:55:41] <rantav> I mean, semantically I have make this correct
[09:55:55] <kali> rantav: nope, it will be the same
[09:55:58] <rantav> let me try two full ranges and see...
[09:56:05] <rantav> oh well… I'll just try....
[09:56:41] <kali> rantav: you have a two dimensional range here. btree indexes are good at single dimension queries
[09:57:13] <rantav> yeah, it still sucks even with two full ranges...
[09:58:13] <rantav> actually, two full ranges was somewhat better
[09:58:35] <rantav> it wasn't like 70 seconds like in the case of two half-ranges, but it was something like 20 seconds
[09:58:47] <rantav> still a bitch, though...
[09:59:02] <kali> i don't get why the first query is so slow though
[09:59:09] <rantav> yeah...
[09:59:21] <kali> you're scanning 1.8M consecutive index entries...
[09:59:44] <rantav> but if they are all in memory, should it be that slow?...
[09:59:49] <kali> rantav: if you run it again, it's the same ? we're not wasting time on an atypical run ?
[10:00:13] <rantav> it's the same more or less, yes, give or take a few seconds here and there
[10:00:19] <rantav> I ran it many times...
[10:00:24] <kali> ok.
[10:00:34] <kali> is it 2.0 or 2.2 ?
[10:00:37] <rantav> sometimes it's 70 secs, sometimes it's 75, sometimes it's 60...
[10:00:42] <kali> ok, ok.
[10:00:59] <rantav> mongo is 2.0.6
[10:01:04] <rantav> aws, ebs
[10:01:36] <rantav> maybe ebs is slow, but again, if the index is in ram, that shouldn't make a diff, right?
[10:03:57] <rantav> There is another strange thing that I can't explain
[10:04:14] <rantav> maybe it's nitpicking, but mongostat reports "faults"
[10:04:30] <rantav> but vmstat on linux reports zero swapping
[10:05:03] <rantav> aren't mongostat-faults and vmstat-swap supposed to be correlated somehow?
[10:13:06] <rantav> kali, I can say one thing for sure - when using two full ranges, it's faster than using two half ranges
[10:13:12] <rantav> it's still terribly slow
[10:13:16] <rantav> but it's faster
[10:13:31] <rantav> it's 60-70 secs from two half ranges
[10:13:42] <rantav> and 15-20 sec for two full ranges
[10:13:53] <rantav> I tried that multiple times
[10:14:34] <rantav> I think 15-20 sec for a query that's indexed is still unacceptable, just for the record...
[10:19:23] <NodeX> ^^ change the query then
[10:22:03] <rantav> nodex, yeah, I will, but still 15 or 20 seconds for a query is lousy… I can't stop there...
[10:23:40] <NodeX> adapt the schema to suit a faster query
[10:23:50] <NodeX> how big is your collection
[10:25:41] <rantav> nodex right now it's 4M
[10:25:45] <rantav> but will grow
[10:26:05] <rantav> will probably be in the order of 20M
[10:26:42] <NodeX> I have collections in excess of 140M and run range queries that take < 1s, not sure why yours would differ
[10:27:32] <rantav> could it be b/c the compound index has elements? Or in other cases (other indexes) 4 or 5?
[10:28:09] <rantav> nodex, kali mentioned that indexes with more than 2 elements are hard on btrees… I wouldn't know...
[10:28:50] <NodeX> your indexes do have alot of elements
[10:29:30] <rantav> yeah, I was trying to follow the "single index per query" guidline...
[10:31:06] <NodeX> maybe it's more efficient to query the range to a tmp collection then query that?
[10:32:17] <rantav> hmmm interesting, I'll look into that
[10:32:28] <rantav> was hoping for a simpler solution but....
[10:32:34] <NodeX> it will depend on your data tbh
[10:32:44] <rantav> anyway, a capped collection is a good choice?
[10:32:55] <NodeX> out of interest what is it for?
[10:33:08] <rantav> User sessions
[10:33:17] <NodeX> in what context?
[10:33:24] <NodeX> stuff like seeing what a user did?
[10:33:42] <rantav> it's an analytical app that keeps data about what users are doing along the session
[10:33:46] <rantav> totango.com
[10:33:52] <NodeX> and you need realtime?
[10:34:13] <rantav> user may use this module or perform this and that action
[10:34:18] <rantav> and I need it realtime, yeah
[10:34:40] <rantav> b/c the UI updates in realtime as users do things on the site
[10:35:03] <NodeX> my approach to realtime (or near as) is every minute process X documents from a history collection (this stores every interaction with my app)
[10:35:40] <NodeX> I group by session id / user id and process say 5k docs at a time which keeps my queries and processing time nice and low
[10:36:19] <NodeX> the caveat is that you need to know what you want to report on before you start
[10:36:26] <rantav> nodex your approach may help performance or insertion of updates
[10:36:33] <rantav> but how does it help perf when querying?
[10:36:34] <NodeX> fortunatley for me I do
[10:36:54] <NodeX> because I limit it to 5000 rows
[10:37:03] <rantav> I mean, if the data is already there and reading is slow, does it matter if it was inserted in batches or not?
[10:37:25] <NodeX> I read 5k docs at a time for example and process it in my app, I dont range query anything
[10:37:25] <rantav> hmmm limit...
[10:37:37] <rantav> let me test if it makes a diff if I add a limit
[10:37:53] <rantav> yeah, but the UI needs those queries (the API really)
[10:38:35] <rantav> The API needs to return the list of session in the past 24h, so...
[10:39:23] <rantav> holy crap
[10:39:38] <rantav> when I limit() the results are SO MUCH BETTER
[10:39:45] <rantav> why didn't I think of that?!!!
[10:41:13] <NodeX> rantav : my method simply grabs the data, if I wanted to query for a range I query on the already processed data
[10:42:02] <rantav> nodex, so, in my model, the Session collection is "the processed data"
[10:42:05] <NodeX> for example I have a report that's got 1 days worth of reads/writes or w/e inside it and a date on it, this is one document and inside it lay nested objects with grouped/reduced actions from a user
[10:42:35] <NodeX> no, the session collection is your live data, you grab 5k docs from it and process them into a smaller collection, then the next minute you grab the next 5k
[10:43:13] <rantav> I guess it depends on your point of view
[10:43:34] <NodeX> In one of my apps I need users as a whole so I save the net result of what all users did ... i/e 50 people searched for Blah.... yours needs individual users
[10:44:00] <rantav> what I do is, a backgroud job processes the events from user activity, each event is a single user action
[10:44:04] <NodeX> it doesn't depend on any POV it's the correct model. You NEED a live collection where the data is dumped
[10:44:23] <rantav> and that backgroud process calculates session data from the stream of user activity
[10:44:31] <NodeX> it's analoguous to message queues, they grab soem data from a job server, process them and continue
[10:45:01] <NodeX> it's the most efficient way of doing it for mine and many apps that require analytics
[10:45:06] <NodeX> analytics / reports
[10:45:25] <rantav> ok, but the things is that I don't know in advance which start/end parameters I'm going to get
[10:45:39] <NodeX> you dont need to
[10:45:46] <rantav> so I can't preprocess the result of the query API into a single document
[10:46:27] <NodeX> you can model the data in such a way that after processing it's still queryable ... only in Smaller chunks
[10:47:55] <rantav> ok, I get that
[10:49:59] <rantav> anyway, for the record, I found two ways that I can improve my query, even without changing the data model
[10:50:17] <rantav> one, is to use a full-range for the start parameter (the end param doesn't matter)
[10:50:48] <rantav> another is to limit(). I didn't realize this could be such a huge factor, but it is...
[10:51:49] <rantav> nodex and I'll think about modifying my data model, I see your point
[10:52:21] <rantav> thanks for your help nodex and kali!
[10:52:25] <NodeX> you're gonna run into scaling issues if you dont
[10:52:30] <NodeX> and no problem
[10:53:28] <rantav> so you're thinking something like groups of session object in resolution of hours, or something along those lines?
[10:53:53] <rantav> grouped into single documents, and keyed by the hour?
[10:54:20] <NodeX> no
[10:54:38] <NodeX> docs per Day with embedded times in the day
[10:54:56] <rantav> ok, but most of my queries are for the past 24h
[10:55:08] <rantav> so I guess a 24h resolution isn't going to help...
[10:55:23] <NodeX> you might want to have a per user doc with a d/m/y stamp and store that 24h in embedded
[10:56:03] <NodeX> uid : foo, datestamp: 08292012, actions : [ {what:'click'.......},
[10:56:59] <rantav> ok, I see your point
[10:59:51] <NodeX> it all depends on your model
[11:00:03] <rantav> yeah, sure, it's a trial and error...
[11:00:09] <NodeX> it's a nice thing to be able to archive chunks of data
[11:00:43] <rantav> yeah, I agree, I already do this in other places...
[12:11:14] <vak> hi all
[12:14:22] <NodeX> vak , easier to ask your question than wait for people to ask you
[12:14:35] <vak> Are there any standard commands to re-arrange documents in a collection according some "master" index? my collection doesn't fit in RAM, so, I'd like to minimize seek operations at least for uch a master index.
[12:15:14] <vak> NodeX: :)
[12:19:44] <NodeX> not really
[12:20:03] <NodeX> delete your other indexes... LRU and MRU take over what is and isn't in RAM
[12:25:49] <vak> NodeX: why to delete others? I need them too... I just wuold like to phisically store data according to one index as much as possible. Kind of defragmentation if you like
[12:26:53] <NodeX> then add more RAM
[12:27:52] <NodeX> you can "db.repairDatabase();" but I assume you ahve already done that
[12:28:09] <vak> NodeX: I'd need terrabytes of RAM then ... not optimal. I just want to re-arrange.
[12:28:15] <vak> repair?
[12:28:44] <NodeX> :)
[12:29:10] <kali> vak: are you aware that depending on what you're doing, chances are the documents are stored in insertion order ?
[12:29:35] <vak> kali: yes I do.
[12:31:00] <vak> NodeX: my collection is OLTP-like. No deletes. So, no "reclaim space" issues. I'm talking only about oder
[12:31:11] <NodeX> awesome
[13:03:37] <Bartzy> Hi
[13:03:53] <Bartzy> An interesting indexing question: I have a likes collection
[13:04:09] <Bartzy> _id, pid (photo_id), uid (user_id) are the keys for each document there.
[13:04:36] <Bartzy> I generally need to find all likes per specific pid
[13:04:46] <Bartzy> and also, I need this to work too:
[13:05:10] <Bartzy> db.likes.find({uid: SPECIFIC_UID_HERE, pid: {$in : [40 PIDs here] })
[13:05:22] <Bartzy> ^ This would return only the pids that the specific user_id really likes.
[13:05:35] <Bartzy> it seems like pid_uid index would solve both queries
[13:06:05] <Bartzy> but I have a problem - the 2nd query will be much more effective with uid_pid, since Monog will only have to look in the index in the uid, then all the PIDs that that user liked are under the same btree "branch"
[13:06:11] <Bartzy> Am I correct in my assumption?
[13:06:25] <Bartzy> And... If I am - is it worth to have both "pid" index and "uid_pid" index, just for that ?
[13:11:26] <[AD]Turbo> when logging with syslog, what is the facility that mongod uses? some of the local1/2/3/4/5/6/7 ?
[13:16:00] <NodeX> Bartzy : http://www.mongodb.org/display/DOCS/Indexes#Indexes-CompoundKeys
[13:17:19] <Bartzy> NodeX: I read that several time, as well as reading the whole MongoDB in Action book
[13:17:24] <Bartzy> And this does not answer my question.
[13:17:40] <Bartzy> several times*
[13:19:56] <NodeX> [14:04:49] <Bartzy> it seems like pid_uid index would solve both queries
[13:20:38] <NodeX> "If you have a compound index on multiple fields, you can use it to query on the beginning subset of fields. So if you have an index on "
[13:20:46] <NodeX> "a,b,c"
[13:21:08] <Bartzy> I know.
[13:21:12] <Bartzy> Please read:
[13:21:16] <Bartzy> <Bartzy> but I have a problem - the 2nd query will be much more effective with uid_pid, since Monog will only have to look in the index in the uid, then all the PIDs that that user liked are under the same btree "branch"
[13:21:19] <NodeX> "you can use it query on "..... "a or a and b or a and b and c"
[13:21:35] <Bartzy> Meaning both indexes could be picked up by the optimizer, and could be used
[13:21:43] <NodeX> then hint()
[13:21:43] <Bartzy> but uid_pid is much more suitable than pid_uid
[13:21:57] <NodeX> or adjust yor schema
[13:21:58] <Bartzy> I want to know if my thinking is really true here!
[13:22:04] <Bartzy> not how to use a specific index
[13:22:06] <Bartzy> please read my question
[13:22:16] <NodeX> I have an answered it the other day
[13:22:34] <NodeX> you didn't believe my answer so you're back again
[13:27:44] <meghan> FYI http://blog.mongodb.org/post/30451575525/mongodb-2-2-released
[13:28:06] <Derick> whoop!
[13:29:18] <NodeX> topic :D
[13:29:34] <NodeX> is there any performance benefits
[13:29:37] <Derick> yes
[13:29:56] <NodeX> I am just about to re-release one of my apps and was wondering whether to upgrade before or not
[13:30:01] <Derick> http://blog.serverdensity.com/goodbye-global-lock-mongodb-2-0-vs-2-2/
[13:30:27] <NodeX> ooo ty ty
[13:30:31] <NodeX> upgrade time
[13:30:57] <NodeX> is it stop, update, start scenario (like the rest)
[13:32:01] <NodeX> and is the apt-* package (mongodb-10gen) updated to 2.2c?
[13:32:04] <NodeX> 2.2*
[13:32:23] <Derick> let me see
[13:34:06] <Derick> NodeX: not yet it seems
[13:34:28] <NodeX> dang
[13:34:34] <NodeX> ok no probs I'll wait
[13:34:43] <Derick> doubt it'll take long
[13:35:11] <NodeX> I wont launch till friday
[13:37:37] <ranman> Derick: packages should be out later today
[13:37:49] <ranman> the debian packages are already out I'm pretty sure
[13:38:08] <Derick> hmm
[13:38:15] <Derick> i just ran apt-get update but didn't see them
[13:39:49] <ranman> hmm, I just worked with Akshay to push those last night but I'm looking at it now and they're not out
[13:39:51] <NodeX> the mongodb-10gen claims to be the (current) stable
[13:40:05] <ranman> Let me go fix that
[13:40:22] <Derick> great :-)
[13:40:54] <NodeX> brilliant, thanks ranman
[13:41:40] <kali> meghan, Derick, kchodorow, other 10gens... congrats :)
[13:42:02] <NodeX> 2.0.5 still :/
[13:42:32] <Derick> thanks
[13:42:43] <Derick> NodeX: hmm, i think mine's 2.0.7
[13:43:05] <Derick> yup
[13:44:22] <NodeX> it saud 2.0.5 when downloading then 2.0.7 when restarting
[13:44:24] <ranman> kk, so I'll get the packages updated later today we found a small error in our packager script
[13:44:24] <NodeX> very strange
[13:44:31] <NodeX> said *
[13:44:35] <ranman> which is why we didn't push it last night
[13:44:36] <ranman> apologies
[13:45:32] <NodeX> no complaints here ;)
[13:45:34] <Derick> NodeX: it says "replacing 2.0.5" I think... apt is a bit odd sometimes
[13:45:43] <NodeX> apt is always odd !!
[13:45:56] <Derick> maybe, but a lot better than rpm :-)
[13:46:06] <NodeX> which is funny because in ENglish being "apt" at somehting means being good/correct
[13:46:29] <NodeX> I guess the linux community has its foibles
[13:50:02] <ansolas> do i understand that correct that gridfs is used to store files ?
[13:51:22] <kali> ansolas: files or big blobs of data, yes
[13:53:22] <ansolas> so I could store anything in grid instead of using the normal way ?
[13:53:47] <ansolas> or is it not possible to save strings or integers to a grid?
[13:54:17] <ansolas> for example i have a user database with a user photo
[13:54:23] <ansolas> how would that be structured ?
[13:54:59] <ansolas> would i just have to store the filename with teh user infos and the picture itself in a separate grid?
[13:57:42] <NodeX> you have what's called meta dataa
[13:58:04] <NodeX> so the file gets stored and the relevant info (perhaps UID / name of user or w/e) inside the meta
[13:58:33] <ansolas> ok so i have to use 2 collections , one for the user info and one for the files ?
[13:59:58] <NodeX> well yes and no
[14:00:01] <NodeX> depends on your data
[14:00:18] <ansolas> ok i see i bet practice will solve this easily
[14:00:22] <ansolas> i try it
[14:00:24] <NodeX> as with most things noSql it's down to your app and how it best suits you
[14:00:31] <ansolas> something else, I found teh following in the skip() doc: Range based paging provides better use of indexes but does not allow you to easily jump to a specific page.
[14:00:39] <ansolas> so whats the proper way to paginate ?
[14:00:46] <ansolas> using Ranges?
[14:00:59] <NodeX> again that depends
[14:01:04] <ansolas> :)
[14:01:15] <ansolas> lets say i have a collection with blog posts
[14:01:26] <ansolas> i collect posts over several years
[14:01:32] <NodeX> I dont have problems skipping upto a few thousand but I save a cache of the total results first time
[14:01:48] <NodeX> some people do have problems do to app design
[14:01:57] <ansolas> and want to disaply only the first 7 last recent headlines
[14:02:14] <ansolas> i tghink skip should be ok
[14:02:30] <NodeX> you dont need skip for the last 7
[14:02:39] <NodeX> only limit(7)
[14:02:51] <ansolas> ok but for the next 7
[14:02:56] <ansolas> ok i see
[14:03:18] <ansolas> looks like i have to try it all myself if its suits my neeeds
[14:03:53] <NodeX> skipping say from 7-14 probably wont be bad becuase they will probably be seqential on disk
[14:04:17] <NodeX> jumping from 7 to 15000000 may cause a speed bump
[14:04:46] <ansolas> ok now I get a better overview
[14:04:58] <ansolas> 15000000 is alot data form my projects
[14:05:28] <ansolas> so It is also possible to cache the most recent calls ?
[14:06:05] <ansolas> should be quite easy with node
[14:06:05] <NodeX> the O/S handles the caching
[14:06:06] <ansolas> :)
[14:06:14] <NodeX> it's MRU / LRU based
[14:06:25] <ansolas> i dont know that stuff
[14:06:38] <ansolas> do i have to enable such caching somewhere ?
[14:06:43] <NodeX> the more you use say a document the more likley it is to be in the cache
[14:06:49] <NodeX> no - it's all auto
[14:06:56] <ansolas> ok thank you
[14:07:01] <NodeX> BUT ..... database calls have an overhead
[14:07:12] <ansolas> looks like i dont have to care about spees at this moment
[14:07:25] <NodeX> for example Mongo is very fast but I cache the last say ten blog posts in Redis to save a call to mongo
[14:07:36] <NodeX> that way if anythign is locked I can still display data
[14:07:56] <ansolas> ok that sound great
[14:08:17] <ansolas> ok enough I am to excited now to type i like to try things out
[14:08:22] <NodeX> lmao
[14:08:23] <ansolas> :)
[14:08:28] <ansolas> bbl
[14:08:29] <NodeX> you sound like me a couple of years ago
[14:08:32] <ansolas> thanks
[14:08:34] <NodeX> njoy, good luck ;)
[14:08:41] <ansolas> yeah :)
[14:30:22] <NodeX> Our model is made possible due to our resiliant infrastructure and scalability thanks to products like MongoDB from our friends at 10gen "
[14:30:23] <NodeX> oops
[14:43:57] <emocakes> k NodeX
[14:43:58] <emocakes> lol
[14:49:58] <ramsey> Derick: I was just having some bit of frustration over DBRef not appearing to work in find() anymore, like my notes from 3 months ago suggest. I thought I recalled seeing examples in the docs, but I can no longer find them.
[14:50:14] <Derick> i've not removed them
[14:50:35] <NodeX> k ?
[14:50:47] <ramsey> Derick: I'm not claiming that you or anyone removed them. I just can't find them. :-)
[14:50:58] <NodeX> [15:43:11] <emocakes> k NodeX ???????
[14:51:00] <Derick> what is your reason for dbrefs?
[14:51:15] <ramsey> Derick: I guess I'm a glutton for punishment ;-)
[14:51:24] <emocakes> 12:29 AM NodeX
[14:51:24] <emocakes> Our model is made possible due to our resiliant infrastructure and scalability thanks to products like MongoDB from our friends at 10gen "
[14:51:24] <emocakes> 12:29 AM
[14:51:24] <emocakes> oops
[14:51:25] <Derick> hehe
[14:51:54] <kali> Our model is made possible due to our resiliant infrastructure and scalability thanks to products like MongoDB from our friends at 10gen "
[14:51:57] <kali> oops, sorry
[14:52:04] <NodeX> it was an oops, was meant to go from a word doc to a blog post
[14:52:18] <Derick> yay, blog posts
[14:52:21] <NodeX> ended up pasted in IRC instead
[14:52:26] <NodeX> hence the "oops"
[14:52:38] <emocakes> i have a blog for my pet ferrets
[14:53:08] <NodeX> I have a blog for blogging
[14:53:08] <emocakes> http://sunnyberrasferrets.blogspot.com.au/
[14:53:16] <emocakes> havent updated it in a while
[14:54:12] <emocakes> Nodex -> http://www.nodex.co.uk ?
[14:54:17] <NodeX> http://new.theukjobsite.co.uk/blog/29-08-12/website-redesign
[14:54:23] <NodeX> but yes that's me too
[14:54:50] <ramsey> Derick: my notes showed something like this: db.assets.find({ catalog : DBRef("clients", ObjectId("4fafca158f4852ebb394f756")) });
[14:54:57] <ramsey> Derick: but that kept giving me this error: error: { "$err" : "can't have undefined in a query expression", "code" : 13629 }
[14:55:01] <NodeX> considering original plus rewrite are mongo based I thought it'd be nice to thank 10gen
[14:55:21] <emocakes> yup
[14:55:22] <ramsey> Derick: I worked around it, though, with this: db.assets.find({ "catalog.$id" : ObjectId("4fafca158f4852ebb394f756") });
[14:55:27] <emocakes> it looks better as well NodeX
[14:55:32] <NodeX> ty
[14:55:37] <emocakes> it implies that you have some sort of personal relationship with them
[14:55:41] <NodeX> original was a rush job
[14:55:42] <emocakes> hence building trust with your reader
[14:55:57] <NodeX> even the blog is mongo powered
[14:56:06] <Derick> ramsey: you mean _id instead of $id ?
[14:56:07] <NodeX> pretty soon my life will be powered by mongo LOL
[14:56:36] <ramsey> Derick: no, a dbref uses $id
[14:56:38] <emocakes> :D
[14:56:44] <kali> NodeX: nice, you can get replicas :P
[14:56:45] <emocakes> i like the idea behind mongo
[14:56:55] <ramsey> { $ref : "clients", $id : ObjectId() }
[14:56:56] <emocakes> for most things rbdm's arent needed
[14:57:02] <Derick> ramsey: uh
[14:57:04] <emocakes> at least for the web i think
[14:57:11] <Derick> ramsey: the _id of a document is sitll the id
[14:57:18] <NodeX> kali : I wish
[14:57:31] <ramsey> Derick: this is what I'm referring to: http://docs.mongodb.org/manual/applications/database-references/#dbrefs
[14:57:50] <Derick> ramsey: yes
[14:57:57] <NodeX> emocakes : since I decided to never use an RDBMS again I have not encountered one problem that I cannot get around
[14:58:06] <emocakes> id like a couple of replicas of myself
[14:58:06] <Derick> the db ref contains a field called $id, but it still points to the normal _id field
[14:58:15] <emocakes> dress them up, play out some weird fantasies with them
[14:58:27] <emocakes> stuff all my ex's said was creepy
[14:58:31] <ramsey> Derick: right, but the work around with "catalog.$id" works correctly
[14:58:33] <NodeX> I have built many many apps for many different purposes and not ran into a single problem that could not be overcome in a day or two
[14:58:47] <Derick> ramsey: that makes no sense
[14:58:52] <emocakes> to me NodeX it seems more like a change of mindset
[14:58:53] <Derick> ramsey: how does your document look like?
[14:59:06] <emocakes> even now I find myself thinking in terms of an rbdms
[14:59:12] <emocakes> foreign keys, join tables etc etc
[14:59:13] <emocakes> haha
[14:59:23] <emocakes> have to stop and be like, hold on
[14:59:46] <kali> well foreign keys and joins still make sense somewhat
[14:59:50] <ramsey> Derick: http://pastie.org/4610669
[14:59:51] <NodeX> luckily I always used rdbms' in a non relational sense anyway
[15:00:16] <NodeX> I seldom joined things, I mostly embedded serialized data from day 1 knowing it was faster to query than to join
[15:00:24] <Derick> ramsey: and what does clients, 4fafca158f4852ebb394f756 point at?
[15:00:25] <NodeX> so the switch for me was seemless
[15:00:28] <ramsey> Derick: that catalog object was created with the PHP MongoDBRef class
[15:01:15] <Derick> ramsey: I think you're confusing a reference stored compared to how to query them
[15:01:21] <ramsey> Derick: it points to a document in the clients collection that has an embedded document called "catalog" with an _id property
[15:01:26] <Derick> yes
[15:01:26] <ramsey> I think I must
[15:01:36] <ramsey> I'm just confused because I swear that used to work
[15:01:43] <ramsey> but maybe I just wrote it down wrong
[15:01:53] <Derick> I don't think you can just query with: { catalog : DBRef("clients", ObjectId("4fafca158f4852ebb394f756")) }
[15:01:59] <ramsey> k
[15:02:19] <ramsey> Derick: so, what is the proper way to query for documents that contain a particular DBRef?
[15:02:50] <NodeX> you have to bring the ref back and parse it out dont you... getDbRef() iirc
[15:02:58] <NodeX> (from what I read yesterday)
[15:03:03] <Derick> ramsey: { "catalog.$id" : ObjectId("4faf... I suppose
[15:03:07] <ramsey> okay
[15:03:10] <ramsey> that works for me :-)
[15:03:12] <Derick> I've never seen the point of dbrefs really
[15:03:30] <NodeX> they seem to just highlight that there is an intended join
[15:03:35] <ramsey> In the way we're using them, I don't see the point, either, because we started using them and then chose not to dereference them
[15:03:52] <ramsey> we could easily have just done catalogId : ObjectId()
[15:03:55] <Derick> just store the ID only - your app should know to which collection they belong
[15:03:57] <Derick> ramsey: right
[15:04:00] <ramsey> and that search would still work fine
[15:04:10] <NodeX> your app is the master of the universe!!
[15:04:18] <ramsey> HE-MAN!
[15:05:00] <NodeX> ramsey : just prey they never get depreciated
[15:05:04] <NodeX> pray/prey
[15:05:28] <ramsey> no worries if they're deprecated
[15:05:38] <ramsey> they're just an object in the db that we can still use
[15:05:45] <ramsey> { $ref : "clients", $id : ObjectId() }
[15:05:48] <ramsey> looks like that
[15:17:14] <scoates> Today (2.2) has been declared "Devops Christmas" in our ops channel. (-:
[15:18:07] <addisonj> Wow... 2.2 is out...
[15:18:43] <Derick> scoates: hehe
[15:19:12] <scoates> it should really help with our faulting issues
[15:31:23] <eka> hi... so I see that mongodb 2.2 is out, but can't find it on the download
[15:31:36] <eka> sorry on the http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/
[15:34:51] <spaam> eka: cool :D
[15:35:04] <vak> when 64bit .deb packages are to be expected?
[15:35:15] <eka> spaam: cool? what is cool?
[15:35:23] <spaam> eka: 2.2 is out :D
[15:35:57] <eka> spaam: yes... old news... can't upgrade cause the package is not there for debian/ubuntu :(
[15:36:15] <eka> I'm waiting for the new aggregation system
[15:36:24] <spaam> same here :)
[15:37:40] <spaam> i got this http://f4d350f66ce8cfe6.paste.se from their repo.. ;S
[15:42:08] <vak> eka: spaam: bad news, it looks like .deb comes 2 days later
[15:42:19] <eka> ouch
[15:42:30] <spaam> vak: and is there any plans to fix the keys for the repo? : )
[15:42:58] <spaam> or should i just wait until next year when debian testing got 2.2? : )
[15:43:25] <vak> spaam: no idea. I'm not from 10gen. btw, I have no key issue.
[15:43:37] <spaam> and you are using debian? :)
[15:43:52] <vak> spaam: ubuntu
[15:44:01] <spaam> ok :)
[15:45:04] <vak> info about 2 days delay is just my date comparison from these two links: http://downloads-distro.mongodb.org/repo/ubuntu-upstart/dists/dist/10gen/binary-amd64/ and http://dl.mongodb.org/dl/linux/x86_64 Do you see any error in conclusion?
[15:50:28] <vak> What is faster -- insert a record with _id field or without?
[15:51:20] <bjori> vak: if you don't provide an _id the driver will generate it for you, and if the driver is broken, the server will
[15:52:02] <bjori> if you have data to use as an id that will be 0.0000000001% faster :)
[15:52:40] <vak> bjori: thx
[15:54:52] <vsmatck> If the user doesn't provide _id it's better to let the server generate it rather than the driver IMO. Less stuff to send over the network.
[15:55:38] <algernon> the advantage of the driver generating it is that if you later want to use the _id for other stuff, you'll already have it at hand, without an extra network round trip
[15:56:01] <ramsey> Derick: here's something weird that I just noticed... it appears that the MongoDBRef class in PHP is creating structures in the DB that look like this: { "$ns" : "collection", "$id" : "1234..." } rather than what the docs say, which is this: { "$ref" : "collection", "$id" : "1234..." }
[15:56:10] <ramsey> Derick: this is version 1.2.12 of the driver
[15:59:09] <Derick> ramsey: let me see
[16:00:44] <Derick> ramsey: no, it doesn't - there is no such thing in the code
[16:00:51] <ramsey> weird
[16:00:56] <Derick> short reproducable script?
[16:01:24] <ramsey> let me see what I can whip up
[16:02:57] <eka> ramsey: are you using anything that wraps the driver? like an ODM or something like?
[16:03:06] <ramsey> eka: Nope
[16:08:33] <ramsey> Derick: I can't reproduce it
[16:10:59] <ramsey> ah ha!
[16:11:13] <ramsey> oh, wait... nevermind :-)
[16:13:14] <ramsey> Derick: I see what's going on now. I'm using MongoHQ, and it appears that they are displaying through the interface $ns in place of $ref (in a DBRef object), but when I use the shell to access the DB directly, I see $ref for the same exact object, so it's not actually stored in the DB as $ns
[16:13:52] <Derick> hm, ok
[16:13:57] <Derick> that's odd
[16:14:09] <ramsey> extremely
[16:14:13] <ramsey> also, very confusing
[16:16:10] <Derick> file a bug with them :-)
[16:16:18] <ramsey> Derick: you can see what I mean here: http://www.evernote.com/shard/s4/sh/4ca017cb-249b-4646-bc4b-7983db6184c9/539198e667a53cc286601eabdb3b17de
[16:16:34] <ranman> packages are out now
[16:16:40] <ranman> 2.2 packages are out I mean
[16:16:46] <NodeX> \o/
[16:16:50] <Derick> woo!
[16:17:17] <Derick> installing ;-)
[16:17:25] <NodeX> Get:1 http://downloads-distro.mongodb.org/repo/debian-sysvinit/ dist/10gen mongodb-10gen amd64 2.2.0 [52.0 MB]
[16:17:26] <NodeX> ;)
[16:17:37] <Derick> i'm done ;-)
[16:18:07] <NodeX> I take it nothing changed in the init.d / mongodb.conf
[16:18:27] <ranman> @NodeX I'm not sure
[16:18:40] <ranman> we might have added some numactl stuff to that
[16:18:55] <NodeX> in the init.d?
[16:19:07] <NodeX> oops, I said "N" lol
[16:22:38] <Derick> ramsey:
[16:22:39] <Derick> erm
[16:22:41] <Derick> ranman:
[16:22:44] <Derick> * Starting database mongodb start-stop-daemon: unrecognized option '--interleave=all'
[16:24:00] <ranman> … well.. that's a problem
[16:24:37] <NodeX> I didn't get that with mine
[16:24:44] <NodeX> but I said No to the init.d update
[16:26:56] <Derick> NodeX: i said yes :-)
[16:27:05] <mog_> I'm looking for a way to both provide a modifier in an upsert query and use a new object if the object isn't found. Is that doable?
[16:30:15] <tyl0r> Do I need to have an arbiter to get the last remaining node (in a 3 node replica set) to become the Master?
[16:30:41] <tyl0r> (assuming 2 nodes failed)
[16:39:12] <eka> vak: 2.2 in the repo already :)
[16:43:24] <vak> eka: cool!
[16:52:27] <ranman> is anyone else having trouble with the packages?
[16:53:29] <timkuijsten> can someone explain what the objects in the oplog with op: "n" are?
[16:53:34] <eka> ranman: using ubuntu here... did an agt-get update then an upgrade for mongo and it's working fine
[16:53:53] <ranman> any problems with the init.d scripts?
[17:02:37] <ribo> is there a mongo 2.0 -> 2.2 migration doc, or just install it and go?
[17:03:53] <eka> ribo: I alway check from version to version... if 2.1 says normal and then 2.2 says normal... so nothing special to de
[17:03:56] <eka> *do
[17:06:18] <ribo> 2.2 is stable today, just curious if people have had any migration stories
[17:10:23] <mog_> is there a way to obtain this behaviour: db.col.update({x: 1}, {$inc: {a: 1}}, {x: 1, a: 1, b: 0, c: 0}) where the third argument object would be inserted in the upsert request if it wasn't found in the first place?
[17:11:22] <ranman> derick: what distro are you on?
[17:14:40] <Derick> debian unstable
[17:15:27] <Derick> ranman: I'm happy to test package if you'd like btw
[17:16:02] <ranman> thanks, I'll hit you up in a little bit
[17:27:10] <sssilver> Hello everyone. I have a BinData field in my collection. Is it possible to use a BinData value as a condition when selecting from it? Thanks
[17:30:33] <IAD> sssilver: try to create a new md5 field for binary data in documents. i'm not sure about using binary data as filter value
[17:38:11] <IAD> BurtyB: 2.2.0 runs faster or you have some errors after the upgrade?
[17:50:52] <BurtyB> IAD, looks OK - numbers in the output are what I'd expect :)
[17:51:54] <eka> BurtyB: so that's a great news
[17:53:05] <BurtyB> eka, yeah I'm well happy :)
[17:53:24] <eka> BurtyB: if that is the case we all are
[17:59:01] <Almindor> is there a way to have mongoimport expect input from stdin?
[17:59:07] <Almindor> I'd love to pipe it gzipped json files
[17:59:12] <Almindor> (55mb vs 900gb)
[17:59:47] <BurtyB> akaIDIOT, don't give it a file and it reads stdin
[17:59:56] <BurtyB> (--file even)
[18:00:03] <Almindor> hmm didn't know that, thanks
[18:00:41] <Almindor> cool, works like a charm :)_
[18:30:15] <TylerE> Is it safe to go straight from 1.8.x to 2.2.0?
[18:40:48] <Industrial> Can I view all queries being made to a mongodb server?
[18:42:05] <Industrial> my /var/log/mongodb/mongodb.log (ubuntu server) doesn't show queries.
[18:44:01] <kali> Industrial: http://www.mongodb.org/display/DOCS/Database+Profiler
[18:46:24] <Industrial> cheers
[18:54:24] <coopsh> Hi, I noticed that all members of a replica set are in state SECONDARY after I ran a stepdown on the current primary
[18:54:38] <coopsh> I measure something between 8-9s or sometimes even 20s or 30s
[18:54:58] <coopsh> ..until a new primary is elected
[18:55:07] <coopsh> setup: 2 normal mongods, one arbiter
[18:55:10] <coopsh> all votes=1
[18:55:24] <coopsh> same behavior for 2.2.0 and 2.0.7
[18:55:45] <coopsh> is this "normal" and expected? is there a way to speed it up?
[19:01:40] <Honeyman> Hello. A weird question: there is no conditional sorting of the output in any form yet, isn't there? I was trying to perform something like db.messages.find({}, {}).sort({user: {'$eq': 'JohnDoe'}, time: 1}) but seems no hope for it...
[19:02:27] <Honeyman> That is, in this case, kind of - 'give me all messages ordered by time, but, if there are messages by JohnDoe, they'll go first'.
[19:03:32] <Honeyman> Is there any legal working way to do that?..
[19:07:51] <sssilver> Is this the right place to ask questions about pymongo?
[19:08:34] <sssilver> I'm trying to understand why for _id it returns a nested structure like this: { "$oid" : "<id>" }, and how can I make it flat, getting rid of $oid
[19:10:47] <Honeyman> sssilver: haven't the result been already preprocessed by something like json_util ?
[19:11:38] <sssilver> Honeyman: you mean it's the result of preprocessing by json_util?
[19:11:56] <sssilver> Honeyman: I'm doing a return json.dumps(classes, default=json_util.default) , yes
[19:12:08] <Honeyman> sssilver: that probably explains it.
[19:12:19] <sssilver> Honeyman: but why am I doing it?
[19:12:26] <sssilver> Honeyman: I don't remember
[19:12:31] <sssilver> there must have been a reason
[19:12:40] <sssilver> I wouldn't just go and write an extra argument, working with a library for the first time
[19:12:44] <sssilver> hmm
[19:12:56] <Honeyman> I bet, the raw "classes" have perfect ObjectIDs
[19:13:28] <Honeyman> Funny, I guessed the problem, without even knowing about the existence of json_util two minutes later
[19:14:07] <sssilver> Honeyman: kudos :)
[19:14:34] <Honeyman> two minutes before
[19:14:48] <Honeyman> Reformulating my question about conditional sorting. Well, since in fact I need only the ONE result, then... $or does NOT guarantee the order of execution, right? Isn't there anything that guarantees?
[19:19:17] <Honeyman> Well, what I probably need is some kind of SQL UNION equivalent...
[19:19:48] <Honeyman> (that would work in findAndModify)
[20:01:20] <vak> hi all
[20:03:13] <vak> just wanted to say thanks to 10gen. After upgrading one part of my calculation takes 30 min instead of 2 hours 30 min. Well, 5x speed up is a nice thing :)
[20:05:54] <bjori> :)
[20:07:47] <bjori> coopsh: a rs.stepDown() should force elections.. but if your overall network is slow it could take few seconds..
[20:08:12] <bjori> coopsh: and if the secondaries are behind the primary things get.. "confusing"
[20:32:02] <coopsh> bjori: network is not slow. all instances run on my desktop. secondaries are in sync. no writes happen while I tested
[21:28:22] <bjori> coopsh: anything interesting going on in the logs?
[21:42:33] <Gargoyle> Greetings.
[21:43:05] <Gargoyle> Is it possible to "tag" an query in code to get it to put something in output.log ?
[21:54:13] <leandroa> hi.. I've been using a .js script on 2.0.4, and it worked fine.. now (since 2.0.7, and even 2.2) I noticed that when I do ObjectId('….').toString(), it returns the entire string, instead of the 24 digits id as string.. is there a better way to do that?
[22:06:25] <leandroa> ah, got it.. ObjectId().str
[22:06:44] <thomasthomas> HI ALL! I am trying to .find({transactions:undefined}).count() and failing any explanation?
[22:07:06] <thomasthomas> Well it's not failing, its returning 0 and I know that's wrong...
[22:09:46] <Gargoyle> thomasthomas: is $exists what you are looking for?
[22:09:47] <leandroa> thomasthomas: try using .find({transactions: {$exists: true}})
[22:10:09] <leandroa> i mean, false.. you're looking for nonexistent ones
[22:12:41] <thomasthomas> leandroa & Gargoyle: thanks but false is returning 0 and true is returning 25327 (all), I've seen transaction equal to undefined when I'm querying.
[22:13:07] <leandroa> thomasthomas: undefined as a string?
[22:14:05] <thomasthomas> no
[22:14:16] <thomasthomas> now it's showing as "transactions" : null
[22:14:42] <thomasthomas> by it's I mean the result from a query db.orders.find({"id":77135202});
[22:15:16] <leandroa> for null you can use: {transactions: {$type: 10}}
[22:15:57] <thomasthomas> db.orders.find({transactions: {$type: 10}}).count(); came back with 0 also =[
[22:17:07] <Gargoyle> Don't you need to pass -1 to $exists?
[22:18:55] <Gargoyle> Oh no. My bad
[22:27:52] <kzoo> ok, pyes and mongodb - please play nice. back for another kick at the can
[22:44:05] <thomasthomas> I have a root level field that is equal to an array sometimes and null others. How can I select all orders when this field "transactions" is null?
[22:49:05] <thomasthomas> I finally figured it out! .find({"transactions.0":{$exists:false}}).count();
[22:49:45] <thomasthomas> db.orders.find({"transactions[0]":{$exists:true}}).count(); comes much more natural ...
[23:41:38] <Bilge> Could you be any more stupid