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.
Models attached to a KeyValue connector get the following *static*
methods:
Color.set(key, value);
Color.set(key, value, ttl);
Color.set(key, value, { ttl: ttl });
Color.get(key);
Color.expire(key, ttl);
Result of compat flag cleanup.
- Current implementation has a wrapper
DataSource.registerType() for
ModelBuilder.registerType(). This removes
the wrapper to encourage use of original
method
If the PK has a definition like
```
"mysql": {
"dataType": "CHAR",
"dataLength":36,
"nullable":"N"
}
```
dataLength is ignored when the PK is used as a foreignKey in other models
Sub models sometimes need to customize the properties from the base model.
This change allows each sub model has its own copy of the base property
definition to avoid potential conflicts across multiple sub models of the
same base.
Rand McKinney
ebarault
Loay
Kevin Delisle
Sakib Hasan
Raymond Feng
jannyHou
Miroslav Bajtoš
Brian Schemp
Amir Jafarian
gunjpan
Ritchie Martori
Ryan Graham
bitmage
Candy
Raymond Feng
nennad
sklyukin
Raymond Feng
Pradnya Baviskar
crandmck
didikeke
Andrey Loukhnov
Fabien Franzen
Clark Wang