Access models related via hasAndBelongsToMany#29
Conversation
|
Test Failed. To trigger a build add comment - ".test\W+please" |
|
Test Failed. To trigger a build add comment - ".test\W+please" |
|
test please |
|
Test Failed. To trigger a build add comment - ".test\W+please" |
There was a problem hiding this comment.
Nice. Maybe include the version numbers in here?
There was a problem hiding this comment.
Good idea, I would include it if the version was easily available. I mean all I have is the app object here. I could probably hack the Node module system to find out what module created the app object and then where the loopback-datasource-juggler is installed, so that I can read its package.json file and get the version, but considering the complexity, I'd rather avoid that.
|
Looks like the build is failing... so that should be fixed. Had a few minor comments that don't really need to be addressed as part of this PR. Overall LGTM. |
|
Thanks @ritch. The build is failing with a strange error and was failing before this PR too :( |
Extract the template of ngdoc comment for a resource method into a function. No changes of functionality.
Sample usage:
// data for the POST /setup request
JSON.stringify({
models: {
Product: { properties: { name: 'string' } },
},
setupFn: (function(app, cb) {
app.models.Product.create(
{ name: 'a-product' },
function(err, product) {
if (err) return cb(err);
cb(null, { productId: product.id }
});
}).toString()
})
The server will run the provided function and wait until the callback
is called. Data passed to the callback are exposed to browser tests
as "testData" and can be accessed via the angular injector:
$injector.get("testData").productId
The LoopBack keeps all models in a static registry. When two tests are using the same model name, some of the model classes may get shared, causing bugs difficult to debug. This commit modifies "/setup" handler to reset the static registry to the initial state every time a new application is created.
The relation "Product hasAndBelongsToMany Category" creates a scope
property on the Product model with three methods: get, create, delete.
At the Angular side, these methods are defined on the Product $resource,
therefore they return the result as Product instead of Category.
The solution presented in this commit has two parts:
1. The Category $resource has internal methods calling remote (REST)
Product.categories.* methods. This way the result is returned
as Category.
2. The Product $resource has extra properties (methods) with hand-coded
implementation delegating to the internal Category methods.
Methods & delegations:
Product.categories()
-> Category['::get::Product::categories']()
Product.categories.create()
-> Category['::create::Product::categories']()
Product.categories.destroyAll()
-> Category['::delete::Product::categories']()
The original scope methods (e.g. prototype$__get__{scope}) are marked
as deprecated, the deprecation text includes the name of the new method
to use.
The URL of prototype methods includes sharedCtor parameters like ":id",
for example
GET /api/Products/:id/categories
Because all $resource actions are static (non-prototype) in ngResource,
callers has to include sharedCtor parameters in the arguments.
Product.categories({ id: productId });
This commit modifies the generated ngdoc to include sharedCtor
parameters in actions for prototype methods.
|
All is well |
Access models related via hasAndBelongsToMany
3 participants
The relation "Product hasAndBelongsToMany Category" creates a scope
property on the Product model with three methods: get, create, delete.
At the Angular side, these methods are defined on the Product $resource,
therefore they return the result as Product instead of Category.
The solution presented in this patch has two main parts:
Product.categories.* methods. This way the result is returned
as Category.
implementation delegating to the internal Category methods.
Methods & delegations:
Product.categories() -> Category['::get::Product::categories']()Product.categories.create() -> Category['::create::Product::categories']()Product.categories.destroyAll() -> Category['::delete::Product::categories']()/to @ritch please review.
Closes #26.
Depends on strongloop/loopback#223 and loopbackio/loopback-datasource-juggler#96.
Related: loopbackio/loopback-datasource-juggler#97, loopbackio/loopback-datasource-juggler#95