Log file Viewer

[05:34:19] <dstanek> is there a way to get pymongo to spit out the queries that it is running?

[08:04:59] <lyrae> Does a schema only need to be created once? If im connecting to the db from a webpage, should i create the schema outside of it? if i do it in the webpage, i'd have to check wether the schema exists or not each time, no?

[08:07:46] <ron> ah? mongodb has no schema.

[08:09:01] <lyrae> this was meant to be in mongoose. apologies

[10:07:55] <bitinn> hi all, we have got a write skew issue we have been thinking about ways to resolve, love to hear some inputs: http://stackoverflow.com/questions/20918396/mongodb-strategies-for-resolving-a-race-condition

[10:35:57] <ppetermann> bitinn: see my reply =)

[10:37:55] <bitinn> thx ppetermann, though given the time constraint this is not really possible for us, plus mongodb is working as intended :)

[10:38:57] <ppetermann> eh?

[10:40:34] <kali> bitinn: what about $set with a version marker for optimistic locking ?

[10:45:21] <bitinn> @ppetermann, i just realize it's a mongodb distribution, not just a fork. it's worth a try, but we are probably more comfortable with updating data model comparing to changing to tokumx in production.

[10:46:13] <ppetermann> its a fork

[10:46:13] <bitinn> i don't know how to direct reply to ppl on freenode webchat, sorry.

[10:47:16] <bitinn> @kali, maybe there is a doc or cookbook for this type of solution? i never heard of version marker strategy, not sure what it involved

[10:47:31] <kali> bitinn: http://docs.mongodb.org/manual/tutorial/isolate-sequence-of-operations/

[10:47:39] <kali> bitinn: but there is actually a simple solution

[10:47:44] <kali> bitinn: stick around

[10:48:07] <ppetermann> and yes i can see why you are reluctant to switch engine - i wasn't aware you had your stuff already running productive.

[10:48:52] <bitinn> @kali cheers

[10:49:27] <bitinn> @ppetermann yeah, we got 100k+ entries at this point, kinda a pain to make a change

[10:50:23] <ppetermann> bitinn: i recently switched a db with several million entries from mongo to toku. but then it was nothing critical

[10:51:25] <ppetermann> although my reasons for switching where different

[10:51:25] <ppetermann> (mostly storage space required)

[10:54:23] <kali> bitinn: I answered in so

[10:54:25] <bitinn> ppetermann: yep, while i admit having this sort of write skew is annoying, it's not service breaking, so arguing we need toku transaction for this particular 1 action would be difficult :)

[10:55:35] <ppetermann> bitinn: i can see that

[10:55:50] <ppetermann> toku has some other advantages as well, (also some huge disadvantages)

[10:58:24] <bitinn> kali: your solution sure is interesting, didn't realize we could filter on query

[11:00:31] <bitinn> i will keep the question unanswered for now, see if better idea comes up

[15:28:48] <OliverJAsh> i'm building a RESTful API on top of a MongoDB. i want to provide pagination for my API resources. would there be anything wrong with using the ID to paginate? i could query the database by saying "ID is less than" — as the ID is like a timestamp?

[15:39:51] <kali> OliverJAsh: nothing wrong at all. it's actualy better than skip and offset

[15:40:00] <kali> skip and limit :)

[15:43:54] <OliverJAsh> thanks kali

[21:06:05] <OliverJAsh> is it okay to rely on ObjectIDs for $gt and $lt queries (for pagination)?

[21:06:53] <OliverJAsh> in theory it should work because of the first 4 bytes being a timestamp, but what about the rest of the ID? what if the document is on a different shard and created at the same time?? would it still be "less than"?

[21:36:08] <kali> OliverJAsh: two document created by two different process in the same second are not necessarily in order. that may affect order locally, but not be a problem for pagination