Asynchronous Setters/Getters

[NuckChorris]

This is important for anyone using bcrypt, including mongoose-auth, which currently relies on synchronous bcrypt functions, which block the entire server while they work.

schema.virtual('password').get( function () {
    return this._password;
}).set( function (password) {
    this._password = password;
    var salt = this.salt = bcrypt.gen_salt_sync(10);
    this.hash = bcrypt.encrypt_sync(password, salt);
});

versus the asynchronous form

schema.virtual('password').get( function () {
    return this._password;
}).set( function (password, done) {
    var _this = this;
    bcrypt.gen_salt(10, function(err, salt) {
        bcrypt.encrypt(password, salt, function(err, hash) {
            _this._password = password;
            _this.salt = salt;
            done();
        });
    });
});

(speaking of which, that is an awful authentication module, at least in the password-auth department — I know I wouldn't trust it.)

[TooTallNate]

Getters and Setters cannot be async, that's just the nature of JS.

I'd recommend using regular functions with a callback instead:

// Virtual Getter
schema.virtual('password').get( function () {
    return this._password;
});

// Setter Function
schema.methods.setPassword = function (password, done) {
    var _this = this;
    bcrypt.gen_salt(10, function(err, salt) {
        bcrypt.encrypt(password, salt, function(err, hash) {
            _this._password = hash;
            _this.salt = salt;
            done();
        });
    });
}

[NuckChorris]

Pretty sure these aren't actually setters in the traditional sense.

On Sep 12, 2011, at 5:39 PM, Nathan Rajlichreply@reply.github.com wrote:

Getters and Setters cannot be async, that's just the nature of JS.

I'd recommend using something regular functions with a callback instead:

// Virtual Getter
schema.virtual('password').get( function () {
   return this._password;
});

// Setter Function
schema.methods.setPassword = function (password, done) {
   var _this = this;
   bcrypt.gen_salt(10, function(err, salt) {
       bcrypt.encrypt(password, salt, function(err, hash) {
           _this._password = password;
           _this.salt = salt;
           done();
       });
   });
}

Reply to this email directly or view it on GitHub:
#517 (comment)

[TooTallNate]

No they are definitely not. The problem is that what you are asking for is impossible, on a JavaScript-level. What I proposed is a "setter function"... in quotes... i.e. as close to the real thing as you could get...

[NuckChorris]

Can't it wait until I call a callback before writing to the database? Seeing as that part is the main detail, not the part handled by js setters?

[TooTallNate]

You could set the password with a virtual setter, and begin the async process after the setter returns, but this would discard the ability to return an Error to the user, should one occur.

I'd really suggest just going with a regular Function. What's so special about the setter syntax?

[NuckChorris]

The main benefit is that the syntax would be much cleaner than with a method. I might be willing to sacrifice error handling for those benefits :/

On Sep 12, 2011, at 6:19 PM, Nathan Rajlichreply@reply.github.com wrote:

You could set the password with a virtual setter, and begin the async process after the setter returns, but this would discard the ability to return an Error to the user, should one occur.

I'd really suggest just going with a regular Function. What's so special about the setter syntax?

Reply to this email directly or view it on GitHub:
#517 (comment)

[TooTallNate]

Well go for it then :/
But really, it's not worth it... Async programming isn't hard, and throwing away Error handling in the name of syntax is... bad

[NuckChorris]

What if it were handled like the middlewares?

[aheckmann]

I would recommend the approach @TooTallNate gave. We will not be adding async getter/setters.

[saransh2012]

@TooTallNate I just needed some clarification regarding what you suggested....Will that method be called automatically when i set password? I doubt it would be so where do I call it?

[TooTallNate]

@saransh2012 You would just call doc.setPassword('foo', function(err){ ... }) directly.

[neverfox]

@TooTallNate What I'd like to be able to do is find a document and have that trigger an asychronous operation that retrieves additional data that lives outside the Mongo database (e.g. scraping a value from a web site at the point in time a related document is fetched), and places that data into the document returned. I understand why it's not possible with getters/setters so virtuals are out (even though it certainly fits the concept of a virtual, viz. these are "attributes that are convenient to have around but that do not get persisted to MongoDB".)

So am I correct to say that the best way to approach this is in the callback of find, doing all my asynchronous decoration there?

[joshuafcole]

While this is evidently not the right route to solve the problem, I feel like having some support for transforming fields when they come out of or are going into the database asynchronously is valuable.

There's no need for the error to be discarded, since they're asynchronous these transform functions would return the usual (err, value) tuple, and any errors could be propagated through whatever function the user called (such as find, update, or save).

This can either be handled through schema properties on fields or through middleware hooks (something between pre and post that gets the value to be returned and can mutate and return it would be excellent), but as it stands I can't seem to find any solution at all except perhaps overriding and wrapping the find method (which is hopefully used by everything as appropriate internally), but that's awfully hacky.

If it would be preferred, I can open a new issue for discussing this.