**Caveats:**
- I have not written any more tests; I perhaps should
- I have not yet written any code to keep current Collections from mixing
strings and ObjectIDs
- I don't actually know if the default should be ObjectID. I should discuss
with people about this.
... but preserve other types on the outside of minimongo.
So far passing all current regression tests, but moment of truth
when we switch over to ObjectID yet to come.
This is a first pass for now; it doesn't support all the types
we will eventually support, and it may be in flux in terms of the exact
format for a little while yet. Also I need to write tests.
But the outline is there.
to mean that the field was cleared, instead of a separate clear list.
Wire format will still have separate clear list
Next step is making a similar change on the client.
Meteor.user.
(Note that if the user object is deleted from the DB after login, you can get
Meteor.userId non-null with Meteor.user null, but arguably this is a feature.)
This branch:
- Updates fibers to 1.0.0, which hopefully fixes crash/stack overflow
issues. This version stops exporting a global 'Fiber' object which
means some server code needs to do some more requires.
- Updates uglify-js to (a Meteor bugfix fork) off of 2.2.3. This is a complete
rewrite of Uglify and appears to fix infinite recursion bugs that were
discovered on the engine branch and while investigating lodash. We also now
are able to minify all code in one pass instead of as separate pieces.
- Stops using a Meteor bugfix fork of fstream, because they have taken our
fork. This also affects the nested copy used by tar.
This definitely won't "work" because both have API changes.
UglifyJS 1 was having issues minifying certain code (eg lodash). But UglifyJS 2
was occasionally segfaulting (as was other code using large regexps). See the
bottom of https://github.com/laverdet/node-fibers/issues/89
Hopefully this will fix it.
Instead of a general client-side sub de-duping mechanism (which mostly existed
for the sake of autosubscribe, and causes issues with server-driven
unsubscribes), make Meteor.subscribe explicitly aware of reactivity.
Expose an "invalidated" flag on Meteor.deps.Context.
Guarantee that invalidation callbacks from different contexts will not be
interleaved at flush time. This has the implication that if you do
context1.onInvalidate(function () {
context2.invalidate();
});
and this is the only way to invalidate context2, then context2's invalidation
callbacks will not be called until after *ALL* of context1's callbacks are
called. This allows us to be sure that the "unsubscribe, unless autorun tried to
re-create an identical sub" logic runs after the autorun function is rerun.
