* 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
validateNumericality didn't test if attributes value is a number
only if it's type is number.
Further nullCheck had a wrong testing order. It first checked if
value is null, later if blank. Also null check only used two equals,
not three. We don't use blank() anymore, testing if variable is
undefined should be fine too.
Added tests covering validateNumericality.
- validateUpsert:true reports validation errors back to the callback
- validateUpsert:false does not call `isValid()` at all
- any other value report validation errors via `console.warn`
When a required number property is set to NaN, for example as a result
of coersion (`Number([1,2,3])`), the "presence" validation now correctly
reports an error.
Fix the implementation of updateOrCreate (a.k.a. upsert) to validate
the model before calling the connector.
In order to preserve backwards compatibility, validation errors are
only logged via console.warn by default.
The correct behaviour, where validation errors fail the updateOrCreate
operation, can be enabled via new model setting "validateUpsert".
Return the raw object data when running on Node v0.11.14+
That way all `inspect` options are always preserved.
When running on older version:
- Honour the depth argument passed to the custom `inspect` function.
- Disable color output, becase there is now way how to detect whether
colors were enabled or disabled by the top-level caller.
When building a list of errors for `ValidationError.message`, include
the values of invalid properties too.
In order to keep the message reasonably short, the values are truncated
at approx 32 characters.
If the validator configured with `{async:true}` option and `if/unless`
condition, validator should be skipped when the condition is un-fulfilled,
so the validator should be pass.
But currently, when skipping the validator, it calls `done(true)` which
accepts a `fail` flag as a param, this will fail the entire validation.
Signed-off-by: Clark Wang <clark.wangs@gmail.com>
Previously validations were appended to an array when configured. The
format was cumbersome, and led to issues. This refactors the
configuration into an object, as a property of the Model.
Note that if no validations have been configured, this property is
currently `undefined`.
Modify ValidationError constructor to include the model name and
a human-readable representation of the validation errors (messages)
in the error message.
Before this change, the message was pointing the reader
to `err.details`. Most frameworks (e.g. express, mocha) log only
`err.message` but not other error properties, thus the logs were
rather unhelpful.
Example of the new error message:
The `User` instance is not valid. Details: `name` can't be blank.
Modify the "unique" validator to accept additional property names to
narrow the space of rows searched for duplicates.
Example:
Consider `SiteUser` belongsTo `Site` via `siteId` foreign key.
Inside every site, the user email must be unique. It is allowed to
register the same email with multiple sites.
SiteUser.validateUniquenessOf('email', { scopedTo: ['siteId'] });
- change `statusCode` from 400 to 422
- nest `context` and `codes` inside `details`
- add `details.messages`
- reword the main error message
Remove the call to Error's constructor from ValidationError constructor,
because it's a no-op - Error's constructor creates a new
instance when called via `.call()`.