Define a new Model method "createOptionsFromRemotingContext" that allows
models to define what "options" should be passed to methods invoked
via strong-remoting (e.g. REST).
Define a new http mapping `http: 'optionsFromRequest'` that invokes
`Model.createOptionsFromRemotingContext` to build the value from
remoting context.
This should provide enough infrastructure for components and
applications to implement their own ways of building the "options"
object.
In strict mode, creating properties on strings is not allowed.
As a result, creating a new datasource fails with the following
error:
TypeError: Cannot create data source "db":
Cannot create property 'name' on string 'mongodb'
In this commit, we fix the code to assign the connector name only
if the connector is an object (not a string).
Add "returnOnlyRoleNames" option to Role.getRoles
Currently the return type of Role.getRoles() method is inconsistent:
role names are returned for smart roles and role ids are returned for
static roles (configured through user-role mapping).
This commit adds a new option to Role.getRoles() allowing the caller
to request role names to be returned for all types of roles.
this is needed because we added allowArray flag to persisted model's
remoteMethod, but when relations try to rebuild such methods, it does
not carry over such flags
Notable side-effects:
- loopback no longer exports "caller" and "arguments" properties
- kv-memory connector is now properly added to the connector registry
- the file "test/support.js" was finally removed
In strong-remoting 3.x, we have stricken the coercion of inputs
methods that are expecting an Object will nolonger accept an array
as input, to preserve backwards compatibility we have added flag
allowArray in remote arguments, which would accept an array of objects
Fix a typo in "app.enableAuth" that caused the method to not detect
the situation when e.g. the built-in User model is already attached
to a datasource.
Fix the definition of "data" argument to
{ type: 'object', model: modelName, ... }
That way strong-remoting passed the request body directly to the model
method (does not create a new model instance), but the swagger will
still provide correct schema for these arguments.
This fixes a bug where upsert in relation methods was adding default
property values to request payload.
Current implementation of `app.model(modelName, settings)`
works as a sugar for model creation. In 3.0, this is
not supported anymore. This implementation reports an
error when sugar is used for model creation.
Includes:
- Updated app.model() method
- Fixed test cases reflecting the change
*Re-mapping `updateAttributes` endpoint to use
`PATCH` and `PUT`(configurable) verb
*Exposing `replaceById` and `replaceOrCreate` via
`POST` and `PUT`(configurable) verb
Prevent apps from crashing when using `Model.nestRemoting` without
`{ hooks: false }` option.
Note that it is not possible to reproduce this bug using our current
Mocha test suite, because other tests modify the global state in such
way that the bug no longer occurs.
Fix `getIdFromWhereByModelId()` to correctly detect the situation
when "bulkUpdate" performs a write operation using a where filter
containing both id attribute but also all other model attributes.
This should significantly improve the performance of change replication,
because the cost of running rectifyAll is very high.
Improve the id-detection algorithm in the "after save" hook
to correctly handle "updateAttributes" as a single-model change
and DO NOT trigger full "rectify all" scan.
The decision which Promise implementation to use should be made by
LoopBack user, not by the framework.
This commit moves Bluebird reference from lib/utils.js to
test/support.js.
Modify `app.enableAuth` to automaticaly setup all required models
that are not attached to the app nor a datasource.
Users wishing to use this option must provide the name of the
data-source to use for these models.
Example usage:
var app = loopback();
app.dataSource('db', { connector: 'memory' });
app.enableAuth({ dataSource: 'db' });
app.use(loopback.rest());
app.listen(3000);
When creating an application with a local registry, the default
behaviour is to define only two core models Model & PersistedModel.
The new flag `loadBuiltinModels` modifies this behaviour and instructs
loopback to define all builtin models in the local registry too.
Process `settings.methods` and `config.methods` as a key-value map
where the key is the method name and the value is an object describing
the method in the format expected by strong-remoting.
Example: a static method `Model.create`
"methods": {
"create": {
"isStatic": true,
"accepts": {
"arg": "data", "type": "Car",
"http": { "source": "body" }
},
"returns": { "arg": "data", "type": "Car", "root": true }
}
}
This patch is based on the code proposed by @mrfelton in #1163.
kobaska
lschricke
Miroslav Bajtoš
ebarault
Amir Jafarian
David Cheung
Candy
David Cheung
Loay
Kogulan Baskaran
Tim van der Staaij
Richard Pringle
gunjpan
Sonali Samantaray
Subramanian Krishnan
Samuel Reed
Miroslav Bajtoš
Rand McKinney
Ryan Graham
Simon Ho
Supasate Choochaisri
Tim Needham
Jue Hou
sghung@ca.ibm.com
Simon Ho
Sam Roberts
Chris Coggburn
Amir Jafarian
Rand McKinney
Miroslav Bajtoš
linguofeng
Miroslav Bajtoš
Richard Walker
Samuel Gaus
Christoph
Pradnya Baviskar
Raymond Feng
Ritchie Martori