findDoc() setAttribute() destroy() to allow table name specified as 1st param

[bguiz]

saveDoc() allows two forms:

From root db object:

db.saveDoc("doggies", {name : "Fido", age : 10}, (err, doc) => { /* ... */});

From "name spaced" db object:

db.doggies.saveDoc({name : "Fido", age : 10}, (err, doc) => { /* ... */});

However, with findDoc() setAttribute() destroy(), this lib only allows the latter "name spaced" variety. The implementation detail of this relies on this being used under the hood, and that means that I need to do Function.prototype.bind() ion my code base.

It would be great if the other document functions also support the former variety, and return an error if the table does not exist yet.

Possible?

[robconery]

I don't see why not... open to a PR if you're willing. The reason we have the override (non namespace) is a convenience for building the table on the fly. The only reason you would need/do that is if you're saving - it doesn't make sense otherwise.

Also - help me understand the this issue some more?

[bguiz]

Yeah I got the rationale behind the two formats with the saveDoc(), that
totally makes sense.

... however there are plenty of use cases (I'm running into in my app)
where tables are created on the fly using saveDoc() ... but in some cases
might be accessed (Read/Update/Delete) before that happens, or more
accurately, attempted to. Thus is we have saveDoc() with one format, it
makes sense to have the other 3 operations also have the same format, where
the order of operations that eventuates cannot be determined ahead of time.

W: http://bguiz.com

On 7 November 2016 at 17:20, Rob Conery notifications@github.com wrote:

I don't see why not... open to a PR if you're willing. The reason we have
the override (non namespace) is a convenience for building the table on the
fly. The only reason you would need/do that is if you're saving - it
doesn't make sense otherwise.

Also - help me understand the this issue some more?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#329 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABsQ2e1hXG8ttvcxgb4Dj0c0OxZXWUgsks5q7sMsgaJpZM4KquGb
.

[bguiz]

Regrading the this - I looked through the massive-js source, and
it's the self variable used within Massive.prototype.* functions.

In my case, I'm doing something along the lines of:

let [err, result] = yield righto(db.saveDoc, 'doggies', {name:'rover'});

(righto is a lib that allow yield-ing callback functions.

and this works perfectly fine. However, attempting to use the second
format means that I need to use bind, like so:

let [err, result] = yield righto(db.doggies.saveDoc.bind(db.doggies),
{name:'rover'});

So for saveDoc() this is obviously not an issue, since I'm quite
happy to use the former method.

However, with the other three operations, I'm forced to use the latter
method, and hence need to use bind in the same way. This is another
reason why I would like to have the root db object expose all of its
method such that it accepts the name of the table in the 1st param.

What do you reckon?

W: http://bguiz.com

On 7 November 2016 at 20:53, Brendan Graetz brendan.graetz@gmail.com wrote:

Yeah I got the rationale behind the two formats with the saveDoc(), that
totally makes sense.

... however there are plenty of use cases (I'm running into in my app) where
tables are created on the fly using saveDoc() ... but in some cases might
be accessed (Read/Update/Delete) before that happens, or more accurately,
attempted to. Thus is we have saveDoc() with one format, it makes sense to
have the other 3 operations also have the same format, where the order of
operations that eventuates cannot be determined ahead of time.

W: http://bguiz.com

On 7 November 2016 at 17:20, Rob Conery notifications@github.com wrote:

I don't see why not... open to a PR if you're willing. The reason we have
the override (non namespace) is a convenience for building the table on the
fly. The only reason you would need/do that is if you're saving - it doesn't
make sense otherwise.

Also - help me understand the this issue some more?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[bguiz]

Ping!