Implement support for the following variants:
- `execute(collection, command, ...params, options)` (MongoDB)
- `execute(...params)` (forward-compatibility & other databases)
Signed-off-by: Miroslav Bajtoš <mbajtoss@gmail.com>
Implement `stop` as an alias for `disconnect`. This way LB4 applications
don't have to include custom `stop` implementation in every datasource
file.
Signed-off-by: Miroslav Bajtoš <mbajtoss@gmail.com>
If establishing a database connection is slow
and database migration runs and there are many
models, sql operations are queued up and this
leads to the node.js max emitters exceeded
warning.
A default value for max emitters has now
been introduced, and it can also be configured
in datasources.json.
Co-authored-by: Dominique Emond <dremond@ca.ibm.com>
When writing tests, for performance reasons we often want to reuse
the same data-source instance for many tests suites. At the same time,
we want to keep such test suites independent and allow them to reuse
the same model name for different model classes.
Juggler does support redefinition of a model with the same name.
This change is adding a new API called that allows tests to remove all
old models before creating new ones. This API would be typically
called from a `before` hook.
Signed-off-by: Miroslav Bajtoš <mbajtoss@gmail.com>
Defer automigrate/autoupdate until we are connected, so that connection
errors can be reported back to callers.
Fix postInit handler to not report connection error to console.log
and via dataSource "error" event in case there is already an operation
queued. When this happens, we want the error to be handled by the
queued operation and reported to its caller.
Signed-off-by: Miroslav Bajtoš <mbajtoss@gmail.com>
add beginTransaction method which calls begin
method from the Transaction class which in turn
calls the connector's beginTransaction method if
it supports transactions.
Co-Authored-By: Miroslav Bajtoš <mbajtoss@gmail.com>
Fix DataSource constructor to create a shallow copy of the settings
object provided by the caller. This prevents surprising behavior
where changes made to `ds.settings` were picked up by the provided
config object, as observed e.g. in tests of our MongoDB connector.
The new version of our config enabled function-paren-newline rule,
this commit fixes the codebase to use more consistent handling
of newlines when calling functions.
Use case:
1. Configure a datasource with lazyConnect = true
2. Do NOT start the DB
3. Start the app
4. Send first request and it fails to connnect to the DB
5. Start the DB
5. Requests are now served correctly
Add API allowing consumers (e.g. LoopBack) to remove a Model from all
juggler registries:
- ModelBuilder's models
- ModelBuilder's definitions
- Connector registry of models
* updateOnly, forceId changes
* support getUpdateOnlyProperties
* fixup! fix updateOrCreate in forceId mode
The contract of `updateOrCreate` is expecting a full object instance
to be passed to the callback.
The current implementation was creating an empty instance and
calling updateAttributes under the hood. As a result, the callback
was called with the attributes being updated only.
In order to preserve existing behaviour, we have to always build
a full initial instance by calling `findById`.
See the following discussion for more context:
https://github.com/strongloop/loopback-datasource-juggler/issues/966
* fixup! fix tests of upsert validation
* move forceId to model-builder
* remove TODO comment
* revert refactoring and test fixes
* Remove duplicate test
* change testcase names
* change to ModeClass.settingse
* forceId setup from datasource to model-builder
* fix inheritance of auto-generated forceId
* Fixed failing tests for auto change
* fixed a comment
In #1298, the spec/doc for polymorphic relations was reviewed
**hasX relation**
- `type`: **hasMany**
- `as`: redefines **this** relation's name (optional)
- `model`: **modelTo**
- `polymorphic`:
- typeOf `polymorphic` === `String`
- matching **belongsTo** relation name
- `foreignKey` is generated as `polymorphic + 'Id'`,
- `discriminator` is generated as `polymorphic + 'Type'`
- typeOf `polymorphic` === `Object`
- `as`: **DEPRECATED** should display a warning,
replaced by `selector`
- `selector`: should match **belongsTo** relation name if the
latter is defined with {polymorphic: true}
- (required) if both foreignKey and discriminator
are **NOT** provided
- (extraneous) if both foreignKey and discriminator
are provided
- `foreignKey`: A property of modelTo, representing the fk to
modelFrom's id.
- generated by default as `selector + 'Id'`
- `discriminator`: A property of modelTo, representing the actual
modelFrom to be looked up and defined
dynamically
- generated by default as `selector + 'Type'`
---
**belongsTo relation**
- `type`: **belongsTo**
- `as`: redefines **this** relation's name (optional)
- `model`: **NOT EXPECTED**: should throw an error at
relation validation
- `polymorphic`:
- typeOf `polymorphic` === `Boolean`
- `foreignKey` is generated as `relationName + 'Id'`,
- `discriminator` is generated as `relationName + 'Type'`
- typeOf `polymorphic` === `Object`
- `as`: **DEPRECATED**: should display a warning,
replaced by `selector`
- `selector`:
- (required) if both foreignKey and discriminator
are **NOT** provided
- (extraneous) if both foreignKey and discriminator
are provided
- `foreignKey`: A property of modelTo, representing the fk to
modelFrom's id.
- generated by default as `selector + 'Id'`
- `discriminator`: A property of modelTo, representing the actual
modelFrom to be looked up and defined
dynamically
- generated by default as `selector + 'Type'`
Before this change, when resolving full connector path, all errors were
ignored. As a result, when the connector was installed but not
correctly built (e.g. loopback-connector-db2 which uses a native addon),
a very confusing message was reported by LoopBack.
In this commit, I am fixing the code handling `require()` errors
to ignore only MODULE_NOT_FOUND errors that contain the name
of the required module.
Defining a model relation with the name "trigger" causes the model not
able to insert records. No error is thrown when a model relation with
the name "trigger" is defined. Adding a check for the model relation
name "trigger" will now throw an error.