Issue with related models export

[pandaiolo]

There is a problem with how relations are dealt with in current impementation of this module.

I feel like relations are not really supported, but if this is the case, they should not be exported.

For example, currently, a related object endpoint will result in lbServices blocks like the following :

    "prototype$__get__products": {
      url: urlBase + "/collections/:id/products",
      method: "GET",
      isArray: true,
    },

This is nice because a collection related products can be pulled out without requiring two separate connections to the API server, using :

Collection.prototype$__get_products({ id: [collection_id] }, function(products) {
    // products are from collection [collection_id]
});

However, there is an issue : prototype$__get_products beeing in the Collection ressource prototype, the resulting objects are considered Collection items by AngularJS !

If I save any of these items, they will be stored in collection database, instead of products....

This feature is seemingly a side effect of raw exporting models API definitions to angular ressources, and is not documented / advised to use.

However, it would be very nice to be able to access related items in the angular services, in a clean and documented way.

[pandaiolo]

Note : for any models using many-to-many relations, I don't see actually any single way to get related records from AngularJS client, because the middle collection/table is not exposed to the client.

Only way I see is to use these methods and manually cast results to correct resource type.

[bajtos]

Thank you for reporting this issue. You are right there is no good way for accessing related items.

The problem has two parts:

1. AngularJS' $resource module does not provide a way how to return a different resource class from resource method. As you described it yourself:

   However, there is an issue : prototype$__get_products beeing in the Collection ressource prototype, the resulting objects are considered Collection items by AngularJS !

2. The remoting metadata used to describe LoopBack methods does not describe the class of object type, thus the code generator can't tell whether the method returns Collection or Product.

I suppose the workaround solution is to extend the auto-generated classes with a hand-written implementation of accessing related items.

// a mock-up, not tested
module.factory('MyCollection', function(Collection, Product) {
  var MyCollection = Object.create(Collection);
  MyCollection.getProducts = function(filter) {
    filter = filter || {};
    filter.where = filter.where || {};
    filter.where.collectionId: this.id;
    return Product.find(filter);
  };
  return MyCollection;
});

Related LoopBack code: relations and scope in loopback-datasource-juggler.

---

This is nice because a collection related products can be pulled out without requiring two separate connections to the API server, using :

Collection.prototype$__get_products({ id: [collection_id] }, function(products) {
  // products are from collection [collection_id]
});

If you are pulling a collection and all related products, then the approach described above will still require two http request: the first one to get the collection, the second one to get related products.

A better solution is to ask LoopBack to include related products in the response of "get collection" request.

// a mock-up, not tested
var result = Collection.find({ filter: { 
  where: { id: collection_id }, 
  include: { 'products' }
}}, function() {
  result.products = result.products.map(function(data) {
    return new Product(data);
  });
});

[pandaiolo]

This last example is indeed better as it brings both collection and related
products items, however, I tried it, and there is an issue for many-to-many
relations at the moment. See here: loopbackio/loopback-datasource-juggler#85

As for the Collection.prototype$__get_products, if you do not need the
collection object, it is the more optimized call for getting this
collection's product items. I suppose in a real-world web/mobile app, the
overhead of server-to-db additional calls for Collection.find(include: products)
is negligible though.

[bajtos]

As for the Collection.prototype$__get_products, if you do not need the
collection object, it is the more optimized call for getting this
collection's product items.

There is one thing I don't understand: when you don't need the collection object, why can't you call directly Product.find?

Product.find({ filter: 
  { where: { collectionId: collection_id } } 
})

The reason why I am asking is to understand better what is your use case, so that we can come up with the best API.

I suppose in a real-world web/mobile app, the overhead of server-to-db additional calls for Collection.find(include: products) is negligible though.

The overhead is negligible for web apps, but may be significant for mobile apps. GPRS/Edge can have latency as high as 150ms.

[pandaiolo]

Sure, it's because I assumed that Product model does not have a
collectionId field available for search, under a many-to-many relation

If it's actually taken care by the API, I would definitely use that !

About the connections overhead, I was more thinking about the differences
between those two cases :

1. Single client-to-API request, single/few api-to-DB call, only related
   products returned, no collection object
2. Single client-to-API request, many api-to-DB calls, both collection
   object and related products are returned

Unless very large audience, I would not regard this difference. As you
point out, the biggest bottleneck is the network between client and API.

(And if there is a significant lag between the API and the DB, I suppose
one should reconsider architecture first before addressing any other issue
:-) )

2014-03-24 19:07 GMT+01:00 Miroslav Bajtoš notifications@github.com:

As for the Collection.prototype$__get_products, if you do not need the

collection object, it is the more optimized call for getting this
collection's product items.

There is one thing I don't understand: when you don't need the
collection object, why can't you call directly Product.find?

Product.find({ filter:
{ where: { collectionId: collection_id } } })

The reason why I am asking is to understand better what is your use case,
so that we can come up with the best API.

I suppose in a real-world web/mobile app, the overhead of server-to-db
additional calls for Collection.find(include: products) is negligible
though.

The overhead is negligible for web apps, but may be significant for mobile
apps. GPRS/Edge can have latency as high as 150ms.

—
Reply to this email directly or view it on GitHubhttps://app.getsignals.com/link?url=https%3A%2F%2Fgithub.com%2Fstrongloop%2Floopback-angular%2Fissues%2F26%23issuecomment-38479401&ukey=agxzfnNpZ25hbHNjcnhyGAsSC1VzZXJQcm9maWxlGICAgKiWy8kLDA&k=83afee91-40a5-4fe0-ce55-1778e9b85ed6
.

[bajtos]

Sure, it's because I assumed that Product model does not have a
collectionId field available for search, under a many-to-many relation

Well, apparently I was wrong, there is no such field yet - see loopbackio/loopback-datasource-juggler#94.

---

I am trying to figure out what to change in the current code generator to make your life easier while keeping the effort required to implement such change low.

I saw your post in the mailing list showing the following snippet:

// Example to get products related to category 42 into the scope in a single API request
$scope.products = [];
Category.prototype$__get__products({ id: 42 }, function(items) {
  // Items are from category 42, but incorrect resource type (`Category`)
  // /!\ They would save to /api/category endpoint instead of /api/product
  // Must cast to `Product` Resource type
  $scope.products = items.map(function(item) {
    return new Product(item);
  });
});

If this is your primary use case, then I can investigate how to modify the generated code to provide the following API:

$scope.products = Category.getProducts({ id: 42 });

(Under the hood, it can be implemented similarly to what you proposed in the mailing list.)

What do you think about that? Would it solve your problem? Is there anything else that needs to be addressed too?

[bajtos]

@pandaiolo I have submitted a patch in #29, will it work for you?

[pandaiolo]

Hi

Many thanks for this fix, it works flawlessly, AFAIC (tested with prod data)

Here is the new code I used (based on the one I shared before) :

$scope.collection = Collection.findById({ id: catId });
$scope.products = [];
$scope.collection.$promise.then(function(c) {
    $scope.products = Collection.products({ id: catId });
});

It makes more sense :-)

Aurelien

2014-04-03 11:52 GMT+02:00 Miroslav Bajtoš notifications@github.com:

@pandaiolo https://github.com/pandaiolo I have submitted a patch in #29#29,
will it work for you?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/26#issuecomment-39433256
.

[pandaiolo]

Also, sorry for not following up your previous message, especially this
question

Is there anything else that needs to be addressed too?

For the moment, I am very happy with the loopback-angular implementation,
as it seem to integrate very nicely into the angular scheme of things. I am
not really an expert, but I just see that I did not met any blocking or
unexpected behaviour.

A bit OT, but I am still working on client/server shared coode. I have to
rework my #25 PR but did not find time for that yet, instead I worked on
another kind of shared code : A shared collection class, a bit like
backbone Collection. This class has to deal with a list of models, so
It's complicated with callbacks prototypes beeing completely different
between angular ressource and loopback models (nodejs style callbacks). Not
sure if it's worth the try...

EDIT: Maybe using Q denodeify

var productFind = angular ? Product.find : Q.denodeify(app.models.Product.find.bind(app.models.Product));

If you have any advice on that topic (shared code dealing with models), I
would really appreciate

Thanks

2014-04-04 15:50 GMT+02:00 Aurelien aurelien@arimaska.net:

Hi

Many thanks for this fix, it works flawlessly, AFAIC (tested with prod
data)

Here is the new code I used (based on the one I shared before) :

$scope.collection = Collection.findById({ id: catId });
$scope.products = [];
$scope.collection.$promise.then(function(c) {
    $scope.products = Collection.products({ id: catId });
});

It makes more sense :-)

Aurelien

2014-04-03 11:52 GMT+02:00 Miroslav Bajtoš notifications@github.com:

@pandaiolo https://github.com/pandaiolo I have submitted a patch in #29#29,

will it work for you?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/26#issuecomment-39433256
.

[bajtos]

If you have any advice on that topic (shared code dealing with models), I
would really appreciate.

I don't have much advice, the idea of using Q.denodeify looks reasonable. I prefer to use Bluebird
instead of Q as the promise implementation, but that's a detail.

What I see as a bigger problem is the difference between the ngResource ($resource) result values and what LoopBack server is returning.

In Angular, Product.find returns an empty array with $promise property.

In LoopBack, promisified (denodeified) Product.find returns a $promise object directly.

@ritch has already started to work on a full-stack example app that will share the code between the AngularJS client and LoopBack server so he will have to solve this problem soon too. You can watch his pull request strongloop/loopback-example-offline-sync#1.

[pandaiolo]

Great, I'll have a look

What I see as a bigger problem is the difference between the ngResource ($resource) result values and what LoopBack server is returning.

Thanks for the input, I have been using the callback argument in many case, instead of the function return, so it happens to be doable this way, however it seems somewhat tricky and makes me unconfortable to push this kind of code to production.

I think i'll keep the shared code more limited, for example with already available resources/models.

Just for the sake of giving you more insight on the case, it's a Basket class, containing basket items.

If I add a new item to the Basket instance, I want it to calculate total price, and display immediately the result on the client, not waiting for API callbacks.

I still want to be able to load a basket on the server, because some operations cannot be done on client (validating payment, adding shipping, etc)

So it'm trying to write all common logic at the same place.