Currently, some adapters pass back the written object on update() or create(), while others pass back a DB response object with metadata (here's looking at you, MySQL).
While the MySQL adapter could be fixed to pass back the written object, the meta information is valuable. I see two clear options for this:
Symbols. Modli could export const meta = Symbol.for('modli.meta'), and metadata could be accessed by accessing either resolvedObject[modli.meta] or resolvedObject[Symbol.for('modli.meta')]
For better support with non-ES6, a non-enumerable _meta property could be defined with Object.defineProperty(objToBeResolved, '_meta', {value: metaDataObj}). The only issue there is that it would overwrite the _meta key if it legitimately existed on the target object.
Edit: For clarity, if the second method is chosen, the only change necessary to modli core would be documentation to standardize the convention.
Currently, some adapters pass back the written object on update() or create(), while others pass back a DB response object with metadata (here's looking at you, MySQL).
While the MySQL adapter could be fixed to pass back the written object, the meta information is valuable. I see two clear options for this:
export const meta = Symbol.for('modli.meta'), and metadata could be accessed by accessing eitherresolvedObject[modli.meta]orresolvedObject[Symbol.for('modli.meta')]_metaproperty could be defined withObject.defineProperty(objToBeResolved, '_meta', {value: metaDataObj}). The only issue there is that it would overwrite the_metakey if it legitimately existed on the target object.Edit: For clarity, if the second method is chosen, the only change necessary to modli core would be documentation to standardize the convention.