<kentonv>
yeah that definitely wasn't there before... and I just reverted to the previous version and ran tests and I see the 19 errors plus all that spam... so something else changed?
<kentonv>
oh, or I never deleted the test app spk and everything just worked for me, but then it got added to `make clean`
<kentonv>
I should have saved a copy before doing "make clean", ugh
<kentonv>
wait that's only ci-clean
<kentonv>
oh clean depends on ci-clean, so yeah
<kentonv>
hey I have an old copy on an old hard drive... hmm
<kentonv>
oh test-app.spk isn't the meteor test app, it's the C++ one
<kentonv>
tried running with an old version of test-app.spk, same results
<isd>
Yeah, the meteor test gets put at tests/assets/meteor-testapp.spk
<isd>
*meteor test app
<kentonv>
right, I was looking at test-app.spk because it was recently added to the set of files deleted by make clean
<kentonv>
so I was wondering if I had been depending on a very old working version
<kentonv>
the test failures seem to be in a lot of tests that have nothing to do with the meteor test app
<isd>
Hm, I remember spot checking them and finding that the few I checked used it, but it's been a month, so maybe I'm misremembering.
* isd
checks
<isd>
Ok, yeah, you're right, a couple of them do use it, but others do not.
<kentonv>
well crap. When I tried to update alpha, all kinds of ensureIndex calls failed
<kentonv>
apparently long ago we created lots of indexes with different options and never noticed
<kentonv>
my local test instance had no issues because apparently its database was initialized relatively recently, with current options
<kentonv>
I deleted the release, hopefully no one had updated in the few minutes it was up
<kentonv>
omfg, Meteor has changed the options on its own internal indexes over time
<kentonv>
so Meteor 2.4 will fail to start when run against any sufficiently old database
<ocdtrekkie>
...wat
<isd>
It's times like these that make me wish we had the manpower to rewrite sandstorm on top of a more sound tech stack. But we do not. So I guess we should open a bug.
<kentonv>
ugh this may have to do with our being stuck on mongo 2.x
<isd>
Even if not, that's going to cause a problem eventually...
<kentonv>
well, migrating is a manual process that we can't ask all our users to do. -_-
<isd>
This is also true.
<isd>
What I want to do (which is not the same as the thing I think is wisest) is to just switch to postgres.
<kentonv>
if we're talking about switching to a totally new database, sqlite probably makes the most sense for self-hosted Sandstorm instances
<kentonv>
no one has enough data to need postgres
<kentonv>
but of course, any migration would be an enormous project
<kentonv>
I can't even monkey-patch createIndex() because Meteor uses it at startup before it runs any app code
<kentonv>
whelp I guess we're stuck on Meteor 2.3 forever
<isd>
Yeah, my reasoning for postgres was more one of migration concerns: postgres has a built-in JSON datatype, so we could just plop our existing tables in without having to first rework the data model, and it has a LISTEN construct that I've seen some libraries use to meteor style stuff with
<kentonv>
ok doing a release now that reverts to Meteor 2.3, blah
<kentonv>
just to fix anyone whose server unluckily updated in the few minutes when I had the broken version up
<isd>
Maybe we could start out by just moving one table, and see how it goes (which we can do since we don't have joins currently...)
<kentonv>
if we're going to write the code to do a background data migration at all, but we don't want to totally rewrite Sandstorm, I think we have to migrate to a newer Mongo, not to postgres. There's going to be way too many little things that change with a different database.
<kentonv>
but even migrating to a newer Mongo seems hard
<kentonv>
we need some sort of thing that runs in the background and migrates data while the server is running. Or we need to ask people to schedule downtime.
<kentonv>
I don't think anyone has time to write this
<kentonv>
so we're probably stuck
<garrison>
Might it be possible to drop any problematic indices on a future version of Sandstorm that is based on Meteor 2.3, before then upgrading to Meteor 2.4 in a later release?
<garrison>
(This would probably be easier to figure out if there we could come up with a straightforward way of generating an old-enough database to cause the problems, rather than having to test on alpha.sandstorm.io.)
<kentonv>
garrison, I don't want to assume everyone has auto-update on and updates with every release
<kentonv>
we could write some code that runs before Meteor starts and directly talks to Mongo to drop the indexes, maybe.