lb-ng sometimes changes methods from Model.updateAttributes to Model.prototype$updateAttributes

[jdforsythe]

Bug or Feature

• Bug
• Feature request

Description of feature (or steps to reproduce if bug)

Since the beginning of the project I'm working on, lb-ng generates the update methods as static updateAttributes() methods on the models, e.g. Model.updateAttributes(). At some point a couple weeks ago, running lb-ng changed all those methods to be Model.prototype$updateAttributes(). I assumed I had inadvertently updated the SDK, so I changed all my update calls to the new prototype$ and everything was working fine. Now I added another remote method to a model and regenerated. They have all switched back to the initial Model.updateAttributes().

All models were changed in the generated lb-services.js, not just the one with the remote method added. Nothing else in the model definitions has changed since the last generation.

Link to sample repo to reproduce issue (if bug)

Expected result

The method names shouldn't change when regenerating the services file

Actual result (if bug)

Additional information (Node.js version, LoopBack version, etc)

Using Node 6.9.4, Loopback 3.4.0

Example diff from previous run (it changed every model like this, and added the one remote method):

diff --git a/client/services/lb-services.js b/client/services/lb-services.js
index 2840b77..88d8e89 100644
--- a/client/services/lb-services.js
+++ b/client/services/lb-services.js
@@ -20141,7 +20141,7 @@ if (typeof module !== 'undefined' && typeof exports !== 'undefined' &&
 
             /**
              * @ngdoc method
-             * @name lbServices.Post#prototype$updateAttributes
+             * @name lbServices.Post#updateAttributes
              * @methodOf lbServices.Post
              *
              * @description
@@ -20173,7 +20173,7 @@ if (typeof module !== 'undefined' && typeof exports !== 'undefined' &&
              * This usually means the response is a `Post` object.)
              * </em>
              */
-        R["prototype$updateAttributes"] = R["prototype$patchAttributes"];
+        R["updateAttributes"] = R["prototype$patchAttributes"];

[bajtos]

Hello, this is rather surprising to me. AFAICT, updateAttributes was always a prototype method on PersistedModel and as such it was always emitted with prototype$ prefix in the client.

Is there anything special about your Post model? What datasource/connector is it attached to? Does it have any custom remote method in addition to those built-in?

Can you provide us with a small app reproducing the problem, per our Bug reporting instructions please?

[mbuster]

Seeing same behavior here. After updating, models no longer have prototype$updateAttributes, only prototype$patchAttributes instead. This makes newly generated client non-backwards compatible with client consumers

[bajtos]

Hello @mbuster, thank you for joining the discussion.

The issue title says the method name changes "from Model.updateAttributes to Model.prototype$updateAttributes" - that's surprising and I don't know how to reproduce that.

The change you are describing - from prototype$updateAttributes to prototype$patchAttributes is sort of expected, especially if you have upgraded your LoopBack version from 2.x to 3.x. However, note that your client should have both methods - see this test.

[mbuster]

Thanks for the response @bajitos, and sorry for the late follow-up on my part. I'll double check all my versions, attempt to re-generate and verify whether I am in fact missing those methods.

[mbuster]

I think the main issue for us is that R['updateAttributes'] = R['prototype$patchAttributes'] is what currently is being generated for each model. However, there used to be a prototype$updateAttributes method for each model, which is now not being generated, though is required for backwards compatibility with some of our client consuming projects. I have temporarily shimmed this with a gulp task after the client library is generated by gulp-loopback-sdk-angular

[bajtos]

I think the main issue for us is that R['updateAttributes'] = R['prototype$patchAttributes'] is what currently is being generated for each model. However, there used to be a prototype$updateAttributes method for each model, which is now not being generated, though is required for backwards compatibility with some of our client consuming projects. I have temporarily shimmed this with a gulp task after the client library is generated by gulp-loopback-sdk-angular

This may be a bug in the way how the SDK is treating aliases. The line you have shown should read the following:

R['prototype$updateAttributes'] = R['prototype$patchAttributes']

AFAICT, this bug has been already fixed in the latest version (v3.1.0 and newer), see lib/services.template.ejs#L185-L189 and #253.

What version of the SDK are you using?

[mbuster]

Looks like I'm running 3.2.0
As I mentioned before, I created a gulp task that shims in the line you mentioned in order to supply a prototype$updateAttributes method, so that's working for now. Just not sure why it isn't happening on its own....

[bajtos]

Hello @mbuster, is this issue still relevant? Could you please create a small application reproducing the issue (see our Reporting issues guidelines)?