Closed nikolaiderzhak closed 9 years ago
$ go version go version go1.4.2 linux/amd64
Fixed it with next patch:
diff --git a/ops_executor.go b/ops_executor.go
index 99d5160..71ee781 100644
--- a/ops_executor.go
+++ b/ops_executor.go
@@ -47,11 +47,11 @@ func (e *OpsExecutor) execQuery(
query := coll.Find(content["query"])
result := []Document{}
if content["ntoreturn"] != nil {
- ntoreturn := int(content["ntoreturn"].(float64))
+ ntoreturn := int(content["ntoreturn"].(int32))
query.Limit(ntoreturn)
}
if content["ntoskip"] != nil {
- ntoskip := int(content["ntoskip"].(float64))
+ ntoskip := int(content["ntoskip"].(int32))
query.Skip(ntoskip)
}
err := query.All(&result)
Let me know if it is ok and I will create PR.
Please guard this with either a two-value type assertion or a type switch (and handle both cases).
Sorry I am not familiar with go lang. Could you show me proper fix ?
@nikolaiderzhak http://play.golang.org/p/yJ9AHa35NI should help
@tmc Thanks Travis. That is from stackoverflow I found too :).
Could you provide ready patch for our case ? I really have dull view of what need to be done with that tricky (for not familiar person) Go syntax.
I will use provided above patch meanwhile. Until I get some spare time to play with that improvement.
I just pushed a patch. Can you try the latest master and see if it fixes your issue? https://github.com/ParsePlatform/flashback/commit/97ad7abae4bb369bf2d8d17a46f267f53530cebb
Travis was I writing my own on this, and you pushed right to master :P Anyhow both ways work, but I worry that we should not set query.Limit vs settings it to 0. It could change the test output if its normally returning 10k or 100k and we ask it for 0.
Thoughts?
@dbmurphy yeah you're right. How about https://github.com/ParsePlatform/flashback/commit/bd3ffb00169a37e7763863f36f03e7ca0af3ea8c ? We just return and log an error if ntoreturn or ntoskip are some type we don't recognize.
Yeah that looks good.
Sorry for delay. I have back to my benchmarking tasks and tested latest master (https://github.com/ParsePlatform/flashback/commit/bd3ffb00169a37e7763863f36f03e7ca0af3ea8c) .
Did not get exceptions. So can I assume that the tool replays recorded operations correctly now ?
Yes, the unprotected type assertion is now fixed.
I am getting this error when starting replay with recorded OUTPUT json and go 1.4.2: