| === kadams54 is now known as kadams54-away | ||
| thumper | storage_test.go:147: | 20:58 |
|---|---|---|
| thumper | c.Assert(info, jc.DeepEquals, expect) | 20:58 |
| thumper | ... obtained state.FilesystemAttachmentInfo = state.FilesystemAttachmentInfo{MountPoint:"", ReadOnly:true} | 20:58 |
| thumper | ... expected state.FilesystemAttachmentInfo = state.FilesystemAttachmentInfo{MountPoint:"", ReadOnly:true} | 20:58 |
| thumper | ... mismatch at .ReadOnly: unequal; obtained true; expected true | 20:58 |
| thumper | WTH? | 20:58 |
| fwereade | menn0, offhand, why does envStateCollection reject bson.M queries? | 21:22 |
| * menn0 has to look at the code | 21:23 | |
| thumper | fwereade: did you see that error above? | 21:24 |
| fwereade | menn0, I think it's just a "nobody uses bsom.M queries" unless you know different | 21:24 |
| fwereade | thumper, huh | 21:24 |
| fwereade | thumper, that's ...interesting :/ | 21:24 |
| thumper | yeah... | 21:24 |
| menn0 | fwereade: I /think/ it was that they weren't being used so YAGNI | 21:24 |
| fwereade | menn0, cool | 21:25 |
| menn0 | fwereade: there's no technical reason they couldn't be supported | 21:25 |
| fwereade | menn0, yeah, I've already written it :) | 21:25 |
| menn0 | fwereade: map based queries are slightly finicky/dangerous anyway | 21:25 |
| menn0 | fwereade: b/c of field ordering | 21:25 |
| fwereade | menn0, just thought I'd better check there wasn't a good reason | 21:25 |
| fwereade | menn0, hmm, can it subtly change complex queries? | 21:26 |
| menn0 | fwereade: more that a query might not used a query if the field order in the query doesn't match | 21:27 |
| fwereade | menn0, I've tended to use bson.D out of habit, but .Ms are often that tiny bit cleaner to write so I've started using them a bit | 21:27 |
| menn0 | fwereade: might not use an INDEX | 21:27 |
| fwereade | menn0, ahhhhh | 21:27 |
| menn0 | sorry... haven't had my second coffee | 21:27 |
| menn0 | I agree .M's are much nicer to write and read | 21:28 |
| menn0 | you just have to be a little more careful | 21:28 |
| fwereade | menn0, anyway, I did not know that, can you point me to an example/doc/something? | 21:28 |
| fwereade | menn0, apart from anythinng else this likely means I've been writing my .Ds in a dumb order, because I don;t know what a good one is | 21:29 |
| menn0 | fwereade: sorry, ignore what I said about indexes | 21:30 |
| menn0 | fwereade: i'm being dumb | 21:30 |
| menn0 | fwereade: i'm was misremembering this: http://devblog.me/wtf-mongo (first section) | 21:30 |
| menn0 | fwereade: .M's are only really a problem if you're trying to exactly match a embedded document | 21:30 |
| menn0 | fwereade: which we rarely/never do | 21:31 |
| fwereade | menn0, ah, ok, cool | 21:31 |
| menn0 | fwereade: so using .M's is almost always fine | 21:31 |
| fwereade | menn0, I suppose I also don't know how it handles repeated names, so a conversion from D to M could be fun if they were significant | 21:31 |
| menn0 | fwereade: do we do that? | 21:32 |
| fwereade | menn0, not as far as I'm aware, but I do the opposite in the M-handling because it seemed most conveniennt (and should be safe ;)) | 21:33 |
| menn0 | fwereade: yep, sure | 21:33 |
| * menn0 slinks away to make another coffee | 21:33 | |
| fwereade | menn0, waigani, thumper: by the way I have a question on http://reviews.vapour.ws/r/2078/ that you might collectively know the answer to | 21:34 |
| fwereade | namely how exactly should cleanupsC interact with env destruction? | 21:36 |
| menn0 | fwereade: cleanupsC was removed at runtime? that rings a slight bell, and also sounds like a terrible idea | 21:36 |
| fwereade | menn0, it was pretty clearly accidental | 21:36 |
| fwereade | menn0, foo := multiEnvCollections; foo.Remove(cleaupsC) | 21:37 |
| fwereade | menn0, can't even remember if it was in code or in test | 21:37 |
| menn0 | fwereade: that does ring a bell | 21:37 |
| fwereade | menn0, either way I raged momentarily and moved on ;) | 21:37 |
| * menn0 checks for that code | 21:37 | |
| fwereade | menn0, it's somewhere in the red in that review, I'm pretty sure | 21:38 |
| menn0 | fwereade: found it. it's in a test. | 21:38 |
| menn0 | fwereade: oh... and in implementation | 21:39 |
| fwereade | ha :( | 21:39 |
| menn0 | there was a func which returned a copy of the multiEnvCollections but without cleanupsC | 21:39 |
| menn0 | / newEnvAliveColls returns a copy of multiEnvCollections minus cleanupsC. | 21:40 |
| menn0 | / This set is used to check if a txn needs to assert that there is a live | 21:40 |
| menn0 | / environment be inserting docs. | 21:40 |
| menn0 | func newEnvAliveColls() set.Strings { | 21:40 |
| menn0 | e := set.NewStrings(multiEnvCollections.Values()...) | 21:40 |
| menn0 | e.Remove(cleanupsC) | 21:40 |
| menn0 | return e | 21:40 |
| menn0 | } | 21:40 |
| fwereade | that's the one | 21:40 |
| fwereade | d} and move on, deal with the fallout later :) | 21:40 |
| menn0 | it was used to decided whether or not to the assertion for env aliveness should be added to a txn.Op | 21:41 |
| fwereade | oh wait that one's ok | 21:41 |
| menn0 | for cleanupsC it shouldn't I guess | 21:41 |
| fwereade | yeah I have a similarly vague understanding of maybe why we might want to do that sometimes but I'm very vague | 21:41 |
| fwereade | I think it's ok to insert into cleanups when an env is dyinng | 21:42 |
| fwereade | menn0, but I don't see why we should preserve cleanups when we nuke env docs | 21:42 |
| fwereade | menn0, that was either happening or I briefly hallucinated it was happening | 21:42 |
| * fwereade is if nothing else a reliable narrator </straight-face? | 21:43 | |
| menn0 | fwereade: it seems like what you've done with ignoreInsertRestrictions covers that previous case | 21:43 |
| menn0 | fwereade: (although I would consider calling it something like allowInsertWhenEnvNotAlive) | 21:44 |
| menn0 | fwereade: i'm not sure about this either. I haven't done much with cleanups. waigani, cherylj and thumper probably know more than me. | 21:45 |
| menn0 | fwereade: where do you see code that preserves cleanups when an env is nuked? | 21:45 |
| * thumper was reading scroll back | 21:53 | |
| thumper | I'm not fully caught up yet | 21:53 |
| waigani | menn0, fwereade: cleanupsC is part of the muliEnvCollections set - so it gets removed along with the others - as the last step of destroying an environment | 21:53 |
| thumper | school hols, and the girls are wanting to play with my new star realms deck | 21:54 |
| thumper | a little time teaching them the rules may mean many hours of freedom | 21:54 |
| waigani | haha | 21:54 |
| fwereade | thumper, nice :) | 21:58 |
| fwereade | thumper, menn0: it's quite possible all I saw was that it wasn't immediately certain whether the removal code in the test would run before or after any other tests that might depend on its presence or otherwise | 22:01 |
| thumper | wallyworld: we should chat when you have a minute or two | 22:41 |
| wallyworld | thumper: sure, give me 5? | 22:41 |
| thumper | ack | 22:41 |
| wallyworld | thumper: 1:1? | 22:51 |
| thumper | yep, there shortly, just writing something | 22:52 |
| waigani | thumper: your bool problem, is the struct being written to/read from mongo? | 23:48 |
| waigani | thumper: from the mgo docs: "Bools are converted to numeric types as 1 or 0 - Numeric types are converted to bools as true if not 0 or false otherwise" | 23:49 |
| waigani | thumper: maybe ppc stores the bools in a weird way | 23:49 |
| waigani | fwereade: ping | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!