A NoSQL analytics engine that embraces post-relational analytics and pushes computation to the data.
Build #9269 (slamdata/quasar#3700) of slamdata/quasar@master in PR slamdata/quasar#3700 by Daniel Spiewak failed in 31 min 31 sec
[slamdata/quasar] New comment by rintcius on pull request #3692: [WIP] Verify from string conversions
@djspiewak no other value than a reminder to me each time I see the list of PRs ;) Closing..
Build #9266 (slamdata/quasar#3705) of slamdata/quasar@master in PR slamdata/quasar#3705 by Daniel Spiewak passed in 252 min 9 sec
Build #9272 (slamdata/quasar#3704) of slamdata/quasar@master in PR slamdata/quasar#3704 by rintcius failed in 3 min 47 sec
[quasar:master] 2 new commits by Daniel Spiewak and 1 other:
`slamdata/quasar@bf75aa9
Doubled compiler stack size (to help avoid intermittent SOE in patmat) - Daniel Spiewakslamdata/quasar@2a850d5` 53.1.5: Doubled compiler stack size (to help avoid intermittent SOE in patmat) - Nic Flores
[quasar:master] 2 new commits by Daniel Spiewak and 1 other:
`slamdata/quasar@d810915
Updated sbt-slamdata - Daniel Spiewakslamdata/quasar@998f04a` 53.1.6: Updated sbt-slamdata - Nic Flores
[sbt-slamdata:master] 2 new commits by Daniel Spiewak and 1 other:
`slamdata/sbt-slamdata@9f4f897
Reconfigured autobump PRs to use the slamdata-bot account - Daniel Spiewakslamdata/sbt-slamdata@e322144` 1.3.1: Reconfigured autobump PRs to use the slamdata-bot account - Nic Flores
Build #9283 (slamdata/quasar#3704) of slamdata/quasar@master in PR slamdata/quasar#3704 by rintcius passed in 255 min 17 sec
Build #9294 (8468c0a) of slamdata/quasar@master by Daniel Spiewak passed in 271 min 19 sec
Build #9295 (slamdata/quasar#3714) of slamdata/quasar@master in PR slamdata/quasar#3714 by Alissa Pajer passed in 253 min 23 sec
[quasar:master] 2 new commits by Alissa Pajer and 1 other:
`slamdata/quasar@c7b6d3e
Adjust signature of Tables#allTables - Alissa Pajerslamdata/quasar@81fde90` 54.1.1: Adjust signature of Tables#allTables - Emrys Ingersoll
[github]
[slamdata/quasar] New comment by rintcius on pull request #3716: The Culling (assigned to alissapajer)
<3 I like the name of your branch too.
I think Slice#toRJsonElements is now dead code. There's probably more dead code, added ch657 in case we want to pick that up.
[github]
[slamdata/quasar] New comment by rintcius on pull request #3716: The Culling (assigned to alissapajer)
There are some obsolete scripts in ./scripts I think: uploadTestData, cleanupMongo.js, genSslTestCerts among others.
Everything in docker is also obsolete, I think.
[github]
[slamdata/quasar] New comment by rintcius on pull request #3716: The Culling (assigned to alissapajer)
addition to @alissapajer 's comments
We can remove mongo* from all the .test files.
In case it saves any time, this is how I've deleted individual connectors from .test files in the past:
$ find . -type f -name "\.test" -print0 | xargs -0 sed -i '' -e '/\S_"mongodb_read_only._$/d'
There are also specific mongodb ITs undertests/mongodbwhich also can be deleted
[slamdata/quasar] New comment by alissapajer on pull request #3716: The Culling (assigned to alissapajer)
@rintcius thumbsup emoji to all the other things that need to be deleted. Let's delete those in a separate PR.
I guess I kind of envisioned a guarantee around
cancelAll where, at some snapshot in time after it is invoked, there are no table ids such that preparationStatus is not Unknown. Without the recursion, we don't have that guarantee.
[slamdata/quasar] New comment by djspiewak on pull request #3718: Removed build stages, cleaned things up, presto! (assigned to nicflores)
[ch674]
[quasar:master] 2 new commits by rintcius and 1 other:
`slamdata/quasar@826a991
cleanup obsolete scripts - rintciusslamdata/quasar@16b009c` 55.0.1: cleanup obsolete scripts - Nic Flores
Build #9319 (slamdata/quasar#3721) of slamdata/quasar@master in PR slamdata/quasar#3721 by rintcius passed in 78 min 47 sec
Resurrected verbatim, modulo
Process => Stream conversion, from the old interface project.
Also resurrected from
interface.
Build #9320 (slamdata/quasar#3723) of slamdata/quasar@master in PR slamdata/quasar#3723 by Emrys Ingersoll passed in 83 min 14 sec
[github]
[slamdata/quasar] New comment by rintcius on pull request #3726: Fixed flaky test in PreparationsManagerSpec (assigned to rintcius)
this PR failed with another failure:
[error] x reject redundant preparation when pending (152 ms)
[error] Normal() != Abnormal(InProgressError(table-id)) (PreparationsManagerSpec.scala:206)
[error] quasar.impl.table.PreparationsManagerSpec$.$anonfun$new$76(PreparationsManagerSpec.scala:206)
[error] cats.effect.internals.IORunLoop$.cats$effect$internals$IORunLoop$$loop(IORunLoop.scala:85)
[error] cats.effect.internals.IORunLoop$RestartCallback.apply(IORunLoop.scala:310)
[error] cats.effect.internals.IORunLoop$RestartCallback.apply(IORunLoop.scala:292)
[error] cats.effect.internals.Callback$AsyncIdempotentCallback$$anon$3.run(Callback.scala:142)
[error] cats.effect.internals.TrampolineEC.cats$effect$internals$TrampolineEC$$localRunLoop(TrampolineEC.scala:62)
[error] cats.effect.internals.TrampolineEC.$anonfun$execute$1(TrampolineEC.scala:54)
[error] cats.effect.internals.TrampolineEC.execute(TrampolineEC.scala:54)
[error] cats.effect.internals.Callback$AsyncIdempotentCallback.apply(Callback.scala:139)
[error] cats.effect.internals.Callback$AsyncIdempotentCallback.apply(Callback.scala:130)
[error] cats.effect.Async$$anon$7.run(Async.scala:163)
[error] Actual: Normal()
[error] Expected: Abnormal(InProgressError(table-id))
Other test(s) seem(s) to have a similar problem (see comment above). Want to address that in this PR?
oh, yes that's tricky but it should work. Not suggesting we should change this now, but I wonder if this code gets less tricky if we'd use a Lock or something instead of
ConcurrentHashMap
Locking is radically lower throughput in the average (no conflict) case and can lead to thread pool starvation. It works but it's not something we want to do unless we have absolutely no other choice. Lock-free algorithms like this one are almost always preferred, even though they are much trickier.
Want to fix the space thing, or should I merge as-is?
One too many spaces removed!
Awwwww… We lost my fancy fixed-point trick! :p
Sure, I can fix the spacing :)
[slamdata/quasar] Pull request submitted by djspiewak (assigned to alissapajer)
slamdata/quasar#3729
Unit tests are a bit lacking because I'm in a hurry but I'm relatively certain that our test coverage is sufficient via the other test suites (especially
StdLibSpec).
[slamdata/quasar] New comment by djspiewak on pull request #3729: Implemented IfUndefined as a primitive in mimir (assigned to alissapajer)
[ch779]
Build #9340 (slamdata/quasar#3729) of slamdata/quasar@master in PR slamdata/quasar#3729 by Daniel Spiewak passed in 76 min 14 sec
Strange the
sys.error was here. I agree with the diff. Maybe UnionColumn had different semantics previously?
Although this doesn't change the semantics; it just throws a more explicit error. And that error is implicit in the contract that we'll call
isDefinedAt prior to calling apply.
[slamdata/quasar] New comment by djspiewak on pull request #3733: Leftshift benchmark (assigned to djspiewak)
@rintcius Unless I'm misreading those results,
bug/slow-shift looks radically slower than master for everything except distinctFieldsObjects. Am I missing something? @jsantos17's testing seemed to show a pretty substantial improvement, so I feel like I'm either misreading your gist, or there's something wrong with our benchmark assumptions here.
[slamdata/quasar] New comment by rintcius on pull request #3733: Leftshift benchmark (assigned to djspiewak)
@djspiewak you have to compare the 2nd and 3rd sections, those are both consuming json. The first section is just there for a comparison with the 2nd (compares json vs materialize consumption on master).
[github]
[slamdata/quasar] New comment by djspiewak on pull request #3733: Leftshift benchmark (assigned to djspiewak)
Oh good! I was misreading then. Looks like a 78% improvement in the best case, a 22% improvement in the worst positive case, and a 97% regression in the worst negative case. I wonder why scalarOrUndefined is so bad. What does the data look like in that case?
This is definitely exciting. I really appreciate you running it on my PR.