search

mizzao / meteor-sharejs

Meteor smart package for transparently adding ShareJS editors to an app
MIT License
225 stars 53 forks source link

Failed to get ops #81

Closed Fafnur closed 7 years ago

Fafnur commented 8 years ago

I using METEOR@1.4.0.1. I changed doc and reloaded application. I saw the error in console:

failed to get ops for "docid": MongoError: Failed to parse: sort: "_id.v". 'sort' field must be of BSON type Object.

How can I fix it?

andy4545 commented 8 years ago

i am also getting this issue - using meteor 1.4.0.1

" failed to get ops for KeCcKETkXWEAewWJv: MongoError: Failed to parse: sort: "_id.v". 'sort' field must be of BSON type Object."

andy4545 commented 8 years ago

It might be related to the error message many people have been getting when starting a meteor app after upgrading to 1.4 +

{ [Error: Cannot find module '../build/Release/bson'] code: 'MODULE_NOT_FOUND' }

(STDERR) js-bson: Failed to load c++ bson extension, using pure JS version

derankin commented 8 years ago

I am getting the error too. Running Meteor 1.4.1.1

(STDERR) failed to get ops for {{id}} : MongoError: Failed to parse: sort: "_id.v". 'sort' field must be of BSON type Object.

Looked into it a little bit, inside of the client-side developer console on initial load returns the following error share.uncompressed.js:642 Could not open document: [object Object]

Looked into the file and it appears shareJs can't open the document/object returned... Help?

premkgowda commented 8 years ago

Any resolution on this topic?. I have been getting the same error

toolX commented 8 years ago

Me, too. Any suggestions?

MalcolmGC commented 8 years ago

I received the same error after running just fine until I did a meteor update:

This project is already at Meteor 1.4.1.1, the latest release. Changes to your project's package version selections from updating package versions: allow-deny upgraded from 1.0.4 to 1.0.5 autoupdate upgraded from 1.2.9 to 1.2.11 babel-compiler upgraded from 6.8.5 to 6.9.1 babel-runtime upgraded from 0.1.9_1 to 0.1.11 binary-heap upgraded from 1.0.8 to 1.0.9 blaze-tools upgraded from 1.0.8 to 1.0.9 boilerplate-generator upgraded from 1.0.8 to 1.0.9 caching-compiler upgraded from 1.0.4 to 1.0.6 callback-hook upgraded from 1.0.8 to 1.0.9 check upgraded from 1.2.2 to 1.2.3 ddp-client upgraded from 1.2.7 to 1.2.9 ddp-common upgraded from 1.2.5 to 1.2.6 ddp-server upgraded from 1.2.6 to 1.2.10 ecmascript upgraded from 0.4.8 to 0.5.8 ecmascript-runtime upgraded from 0.2.12 to 0.3.14 es5-shim upgraded from 4.5.13 to 4.6.14 fastclick upgraded from 1.0.11 to 1.0.12 geojson-utils upgraded from 1.0.8 to 1.0.9 html-tools upgraded from 1.0.9 to 1.0.10 http upgraded from 1.1.5 to 1.1.8 launch-screen upgraded from 1.0.11 to 1.0.12 logging upgraded from 1.0.12 to 1.1.15 meteor upgraded from 1.1.16 to 1.2.17 minifier-css upgraded from 1.1.11 to 1.2.14 minifier-js upgraded from 1.1.11 to 1.2.14 minimongo upgraded from 1.0.16 to 1.0.17 modules upgraded from 0.6.5 to 0.7.6 modules-runtime upgraded from 0.6.5 to 0.7.6 mongo upgraded from 1.1.7 to 1.1.12 npm-mongo upgraded from 1.4.43 to 1.5.49 ordered-dict upgraded from 1.0.7 to 1.0.8 promise upgraded from 0.7.3 to 0.8.4 random upgraded from 1.0.9 to 1.0.10 reactive-dict upgraded from 1.1.7 to 1.1.8 reload upgraded from 1.1.8 to 1.1.10 retry upgraded from 1.0.7 to 1.0.8 routepolicy upgraded from 1.0.10 to 1.0.11 session upgraded from 1.1.5 to 1.1.6 spacebars-compiler upgraded from 1.0.11 to 1.0.12 standard-minifier-css upgraded from 1.0.6 to 1.2.0 standard-minifier-js upgraded from 1.0.6 to 1.2.0 templating upgraded from 1.1.14 to 1.2.14 tracker upgraded from 1.0.14 to 1.1.0 url upgraded from 1.0.9 to 1.0.10 webapp upgraded from 1.2.8 to 1.3.11 Newer versions of the following indirect dependencies are available:

alextanton commented 8 years ago

I am getting the same error. Happened after I updated to 1.4

andy4545 commented 8 years ago

@MalcolmGC I created a new meteor project and only added the mizzao:sharejs package on top of the basic meteor install using iron-cli. The same error occurred in this basic project - therefore the issue must lie with :

1) One of Meteor's core packages 2) With Meteor 1.4 + itself.

Unfortunately I only ever used mizzao:sharejs after 1.4 meteor came out - therefore I have not experienced it fully working.

derankin commented 8 years ago

@andy4545 @MalcolmGC @mizzao In the release of Meteor 1.4 --

We’ve upgraded the version of MongoDB that ships in the dev bundle from version 2.6.7 to 3.2.6, along with an updated version of the driver. The development database for new apps will now default to using the WiredTiger storage engine; however, you can still connect to databases running the old MMAPv1 engine. You can now also pass additional connection options to the Mongo driver by calling Mongo.setConnectionOptions(options), which allows configuring certificates for SSL encryption, for example.

A huge shout out to @fabs, the Meteor community member who did the bulk of the engineering work for this update.

I assuming the problem lies within the new MongoDB version and driver. Looking into a fix.

learnsomuch commented 8 years ago

For meteor 1.4.1.1, If we reset mongoDB using "meteor reset", then sharejs works. But if we restart meteor server, then we are getting the same error. Basically, For every new id, it works for first time and fails after restart. if we create a new entry in Mongo, that works as long as server doesnt restart.

AkshayND commented 8 years ago

But then, what should we do if we had to edit previous entry and we had restarted the server?

learnsomuch commented 8 years ago

That issue needs to be fixed from their end. I am still not sure if this problem is from MongoDB or sharejs

DavidSichau commented 8 years ago

For me this problem was with the old MMAPv1 engine of meteor. With a switch to WiredTiger this problem was resolved.

We use this package with the meteor 1.4.1 since the release of it without problems, with a WiredTiger Storage engine.

cyyeh commented 8 years ago

https://projectricochet.com/blog/why-you-want-use-wiredtiger-meteor-14#.WBDrNo99670

Here is the solution to the problem.

DavidSichau commented 8 years ago

I close it as it the problem can be solved by switching to wireTiger

derdaumen commented 8 years ago

For meteor 1.4.1.1, If we reset mongoDB using "meteor reset", then sharejs works. But if we restart meteor server, then we are getting the same error. Basically, For every new id, it works for first time and fails after restart. if we create a new entry in Mongo, that works as long as server doesnt restart.

I followed the article linked by @Cure100061148

https://projectricochet.com/blog/why-you-want-use-wiredtiger-meteor-14#.WBDrNo99670

and encounter the same behaviour. This issue is closed but I can't see how this behaviour got solved.

I would appreciate help!

DavidSichau commented 8 years ago

Can you print me the command of mongo shell after a restart:

db.serverStatus().storageEngine
kongyujian commented 8 years ago

Hi, i've been experiencing the same issues as well even after following the above instructions. The following is the result after running the mentioned command.

{ "name" : "wiredTiger", "supportsCommittedReads" : true, "persistent" : true }

I've actually tried more than the recommended instructions. I've looked into my own environment variables to ensure that everything is up to spec. I'm currently on Meteor 1.4.2, but i've run meteor in multiple configurations from 1.4.0 to 1.4.1 to even 1.4.2, but to no avail. The versions for my sharejs and ace editor are as follows: mizzao:sharejs@0.9.0 mizzao:sharejs-ace@1.4.1

Have done extensive searching online as well, not sure if its related to the following: https://github.com/josephg/ShareJS/pull/410/files

Appreciate the help!

DavidSichau commented 8 years ago

So this seems to be a upstream problem with sharejs.

I will follow this and as soon as they update sharejs I will merge it into this.

In the mean time you habe the choice to disable the persistent storage of sharejs and switch to in memory storage.

kongyujian commented 8 years ago

Ahhh ok! Would there be any implications to an app in a production environment if such a switching is done?

DavidSichau commented 8 years ago

We use it in production since the release of 1.4 without any problems. However we store the editors data every 10sec in our own db. If no one has open the document all sharejs data is droped such that only changes in the current editing session are synced.

derdaumen commented 8 years ago

Sorry for not replying, I was offline for a week.

The output I get for db.serverStatus().storageEngine is:

meteor:PRIMARY> db.serverStatus().storageEngine
{
    "name" : "wiredTiger",
    "supportsCommittedReads" : true,
    "persistent" : true
}

The idea to switch to in memory storage is very helpful, since my app already saves a copy of the editors data at the end of editing to a separate location.

However, I can't figure out how to paste the text that I saved to my own db back into the shareJs textarea to pickup editing where it was left? This is my current attempt:

Template.shareJSFormField.rendered = function() {
  let textarea = $(this.firstNode);
  let data = this.data;
  let lastSavedText = textsCollection.findOne({
    _id: data.textId
  });
  if (lastSavedText.content) {
    textarea.val(lastSavedText.content);
  }

but it doesn't work. The shareJS textarea stays blank. Can anyone help me with this?

DavidSichau commented 8 years ago

We add the document on the create function on shareJS on the Server side. Here is our code we use for that. The documents are stored in MDs.md. Hope this helps you,

import { ShareJS } from 'meteor/mizzao:sharejs';
import { Meteor } from 'meteor/meteor';
import _ from 'underscore';

/* globals MDs */

const updateMd = function updatedMd(mdId, md) {
    if (!_.isEmpty(md)) {
        MDs.update({ _id: mdId }, {
            $set: { md },
        });
    }
};
Meteor.startup(() => {
    ShareJS.model.on('applyOp', Meteor.bindEnvironment((docName, opData, snapshot) => {
        // do not log original document
        if (opData.v > 0) {
            updateMd(docName, snapshot);
        }
    }, () => {
        console.log('Failed to bind environment applyOp');
    }));

    ShareJS.model.on('create', Meteor.bindEnvironment((docName) => {
        const md = MDs.findOne(docName);
        const opData = {
            op: [{ i: md.md, p: 0 }],
            v: 0,
            meta: {},
        };
        ShareJS.model.applyOp(docName, opData, (err) => {
            if (err) {
                console.log(err);
            }
        });
    }, () => {
        console.log('Failed to bind environment create');
    }));
});
ChanJuiHuang commented 7 years ago

Hi there: My meteor's version is 1.4.2.3. However I restart the meteor that mongo still display storageEngine which is mmapv1. My OS is win7 64bit. What can I resolve this problem?

When I changed the OS to debian 8.6(64-bit), I got the wiredTiger. However I still get the same error that I use package is mizzao:sharejs-codemirror. Please help me!

This is my mongo commend : db.serverStatus().storageEngine { "name" : "wiredTiger", "supportsCommittedReads" : true, "persistent" : true }

PS My package is mizzao:sharejs-codemirror

Thank you for your help!

DavidSichau commented 7 years ago

With Version 0.10.0 the default behaviour was changed that in memory storage is the default.

The problem with the other part is that it is a upstream problem with sharejs, which seems not be maintained anymore.

ricardodovalle commented 7 years ago

Hi @DavidSichau , Whats is the best way to solve it and keep using meteor-sharejs? Thanks.

DavidSichau commented 7 years ago

@ricardodovalle Switch to in memory storage and make snapshots on the server which are stored to the DB.

wagnerjs commented 7 years ago

@DavidSichau how I can switch to in memory storage?

DavidSichau commented 7 years ago

You can use Version 0.10.0 where this is the default. Otherwise change your Setting file that type is not equal to mongo: https://github.com/mizzao/meteor-sharejs/blob/master/settings-example.json

derdaumen commented 7 years ago

@DavidSichau thank you so much for your help! You saved my life.

After long absence from this project I finally tried your suggestion and

ShareJS.model.on('create', Meteor.bindEnvironment((docName) => {

works like a charm for inserting content at the beginning of a session.

Out of curiosity I also tried your suggested

ShareJS.model.on('applyOp', Meteor.bindEnvironment((docName, opData, snapshot) => {

but there I get an error: Failed to bind environment applyOp [Error: Meteor.userId can only be invoked in method calls. Use this.userId in publish functions.]

I currently can't identify the problem in my code and am wondering if the cause is to be found this package or the share shareJS package. Any ideas?

Here is my adjusted version of your suggestion:

const updateScenario = function updatedScenario(docId, snapshot) {
    if (!_.isEmpty(snapshot)) {
        let index = docId.indexOf('-');
        let scenarioId = docId.substring(0, index);
        let fieldName = docId.substring(index + 1);
        Scenarios.update({ _id: scenarioId }, { $set: { [fieldName]: snapshot }});
    }
};
Meteor.startup(() => {
    ShareJS.model.on('applyOp', Meteor.bindEnvironment((docId, opData, snapshot) => {
        // do not log original document
        if (opData.v > 0) {
            updateScenario(docId, snapshot);
        }
    }, (error) => {
        console.log('Failed to bind environment applyOp', error);
    }));

    ShareJS.model.on('create', Meteor.bindEnvironment((docId) => {
        let index = docId.indexOf('-');
        let scenarioId = docId.substring(0, index);
        let fieldName = docId.substring(index + 1);

        const scenario = Scenarios.findOne(scenarioId);

        const opData = {
            op: [{ i: scenario[fieldName], p: 0 }],
            v: 0,
            meta: {},
        };
        ShareJS.model.applyOp(docId, opData, (err) => {
            if (err) {
                console.log(err);
            }
        });
    }, () => {
        console.log('Failed to bind environment create');
    }));
});
DavidSichau commented 7 years ago

I do not see the Problem in your code, do you have any methods that are executed on the Scenarios Collection, which depend on userId? Like a default or autovalue field.

rajit commented 7 years ago

In ShareJS upstream, this successfully fixes the issue: https://github.com/josephg/ShareJS/pull/410

DavidSichau commented 7 years ago

@rajit Thanks for the info. As soon as this gets merged and publish I will update this package.

rajit commented 7 years ago

Don't hold your breath, it's been 6 months!

I've forked it here https://github.com/qeek/sharejs-tmp-fork and am using that for now:

Npm.depends({
  // Fork of 0.6.3 that doesn't require("mongodb"):
  // https://github.com/meteor/meteor/issues/532#issuecomment-82635979
  // Includes "Failed to parse" bugfix
  share: "https://github.com/qeek/sharejs-tmp-fork/tarball/94c059bd4da24de8e6e90fb83484dd9c7b0efd59"
});

Also needs a minor change in meteor-sharejs to require BCSocket correctly.

I'll open a pull request.

rajit commented 7 years ago

Pull request opened: https://github.com/mizzao/meteor-sharejs/pull/84

DavidSichau commented 7 years ago

@rajit Thanks for your effort. sharejs base version 0.10.1 is now released which will fix this problem with mongo 3.2 or later.

rajit commented 7 years ago

For anyone coming looking for a solution to this, unfortunately 0.10.1 did not work for me. I've submitted https://github.com/mizzao/meteor-sharejs/pull/85. If it gets merged and released that should work. Until then I've published rajit:sharejs on Atmosphere which does work for me.

DavidSichau commented 7 years ago

It is merged and released as 0.10.2.

rajit commented 7 years ago

Fantastic, thank you! I can confirm that 0.10.2 works for me, I'll remove rajit:sharejs.