LiveDB Question

[Simon Last]

Hello,

I'm experimenting with using LiveDB for a project. Am I correct in thinking that LiveDB will actually perform OT, or does it just store data?

Here's the example code I'm trying to run:

livedb.submit('users', 'yyy', {create:{type:'json0', data:{q: [1,2,3]}}}, function(err, version, transformedByOps, snapshot) {});

This does what I expect, returning the snapshot: {"q": [ 1, 2, 3 ] }

livedb.submit('users', 'yyy', {op:{p:["q",0], li:"hello"}, v:1}, function(err, version, transformedByOps, snapshot) {});

The ops are what I expect here:

[

  {

    "op": {

      "p": [

        "q",

        0,

        0

      ],

      "li": "hello"

    },

    "m": {

      "ts": 1395121154507

    },

    "v": 7

  }

]

But the snapshot doesn't seem to change: {"q": [ 1, 2, 3 ] }

Is it supposed to apply the operation?

Thanks,

Simon

[Joseph Gentle]

It should, change the snapshot. But an error might have happened - and
you're swallowing all errors with that callback function. Replace it
with something like this and take a look at what the error is.

function(err) { console.error(err); }

> --
> You received this message because you are subscribed to the Google Groups
> "ShareJS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sharejs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Simon Last]

There are no errors

Here are the arguments returned from the first callback:

{

"0": null,

"1": 0,

"2": [],

"3": {

"v": 1,

"data": {

"q": [

1,

2,

3

]

},

"type": "http://sharejs.org/types/JSONv0",

"m": {

"mtime": 1395165256689,

"ctime": 1395165256689

}

}

}

And the second:

{

"0": null,

"1": 2,

"2": [

{

"op": {

"p": [

"q",

0

],

"li": "hello"

},

"m": {

"ts": 1395165266975

},

"v": 1

}

],

"3": {

"data": {

"q": [

1,

2,

3

]

},

"type": "http://sharejs.org/types/JSONv0",

"v": 3,

"docName": "qqq",

"m": {

"mtime": 1395165270708,

"ctime": 1395165256689

}

}

}

You received this message because you are subscribed to a topic in the Google Groups "ShareJS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sharejs/mplwmdvulYs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sharejs+u...@googlegroups.com.

[Simon Last]

The second one was after I called the second function twice. The first time, it returned this:

{

"0": null,

"1": 1,

"2": [],

"3": {

"data": {

"q": [

1,

2,

3

]

},

"type": "http://sharejs.org/types/JSONv0",

"v": 2,

"docName": "qqq",

"m": {

"mtime": 1395165266993,

[Joseph Gentle]

The problem is that your op needs to be in an array.

client.submit('users', 'yyy', {op:[{p:["q",0], li:"hello"}], v:1}, ....)

[Simon Last]

Works perfectly! Thank you.

I have a few architectural questions, if you don't mind.

My application will need to store tens to hundreds of thousands of very small JSON documents (<1k). Will liveDB perform well in this scenario?

I notice that liveDB uses Redis internally. Why is this?

To unsubscribe from this group and all of its topics, send an email to sharejs+u...@googlegroups.com.

[Joseph Gentle]

On Tue, Mar 18, 2014 at 11:11 AM, Simon Last <stl...@gmail.com> wrote:
> Works perfectly! Thank you.
>
> I have a few architectural questions, if you don't mind.
>
> My application will need to store tens to hundreds of thousands of very
> small JSON documents (<1k). Will liveDB perform well in this scenario?

Livedb doesn't store the data - its stored in mongo (or whatever your
backend database is). Livedb hasn't been the bottleneck for us,
although the query support is slow (it polls, and its seriously not
efficient if you have a lot of outstanding queries).

> I notice that liveDB uses Redis internally. Why is this?

Livedb needs a way to atomically increment the version of a document.
(Its designed assuming you have multiple frontend servers, and it
needs an ultimate source of truth).

It currently uses a lua script in redis to do this. I made a prototype
version which uses transactions in livedb to do the same thing, but I
haven't reimplemented queries there. I'd also like to factor the code
to make redis optional (so you don't need redis if you aren't scaling
past one machine), but I haven't done that yet.

-J

[Simon Last]

Does this mean I can omit version numbers? In the documentation it says:

"You should always specify the version when submitting operations. If you don't, operations will do funny things in the face of concurrency."

[Joseph Gentle]

If you omit version numbers, it'll always append the operation (it
defaults to the current version of the document +1)

.. Which is useful sometimes on the server.

[Simon Last]

So, how do I deal with concurrent operations? Do I pass in the last known version when an operation was created?

[Joseph Gentle]

Yeah that's right.