Comments (17)
The doc needs to be updated. See an example at https://github.com/strongloop/loopback-example-app/blob/master/common/models/car.json
from loopback-boot.
The difference is that each json contains one model in 2.0. name
becomes a property instead of the key. For example,
1.x:
{
"myModel": {
"properties": {}
}
}
2.x:
{
"name": "myModel",
"properties": {}
}
from loopback-boot.
from loopback-boot.
This leads to a very awkward situation when options.models
is passed explicitly; I autogenerate model schemas based on a few data sources, and the validator is assuming that I want to use the _meta
field and load model configurations from disk. Even if I found a way past the validator, explicit models
configuration is ignored in buildAllModelInstructions
.
from loopback-boot.
Do you mean discovery?
from loopback-boot.
Yes, but from a custom connector. I was unable to find satisfactory docs in the past on how to set up autodiscovery 'correctly' so I do some custom model definition munging, which is probably not ideal but should be possible, IMO.
from loopback-boot.
Does the custom connector produce the model definition in 1.x format (a json object containing multiple models keyed by model name)?
from loopback-boot.
Yes, exactly - I would read in my current models.json
, apply updates and inserts, and pass that to app.boot
.
On Jul 24, 2014, at 12:22 AM, Raymond Feng [email protected] wrote:
Does the custom connector produce the model definition in 1.x format (a json object containing multiple models keyed by model name)?
—
Reply to this email directly or view it on GitHub.
from loopback-boot.
I wonder if we should add back the ability to define multiple models in one JSON file as 1.x in addition to the 2.x style. What do you think?
from loopback-boot.
The documentation page "Model definition reference" is wrong, we need to update it for 2.0. Please see Migration guide - models for now.
I wonder if we should add back the ability to define multiple models in one JSON file as 1.x in addition to the 2.x style. What do you think?
I am rather opposed to that idea, it will add more complexity and maintenance overhead. We still need to decouple model definition (properties, options) from model configuration (datasource) for full-stack apps with an isomorphic client, which means the format of such multi-model JSON file will be different from 1.x models.json
.
Yes, exactly - I would read in my current
models.json
, apply updates and inserts, and pass that toapp.boot
.
This is an interesting use case that I did not consider while working on loopback-boot 2.x.
As an immediate solution/workaround, you can use [email protected]
. It is 100% compatible with app.boot
from loopback 1.x and it works with loopback 2.x too.
In the longer term, I can extend the options
argument of boot
/compile
to allow you to supply:
- Your own model instructions (i.e. an array of objects conforming to what
buildAllModelInstructions
returns). The compiler will not read any model-related files at all. - Your own model definitions (to replace the result of
findModelDefinitions
). Together with the existingoptions.models
, it will allow you to specify all model-related data and still use the benefits which loopback-boot provides (most notably loading models in order defined by inheritance, i.e. base models are loaded before models that are extending them).
Thinking about it again, I think the second item is the best.
boot(app, {
models: {
Car: { dataSource: 'db' },
// etc.
},
modelDefinitions: [
{
definition: {
name: 'Car',
properties: { /*...*/ }
},
sourceFile: 'path/to/car.js'
},
// etc.
]
});
from loopback-boot.
Maybe we should introduce the ldlVersion
into the _meta property so that the boot code can tell which format the json conforms to.
from loopback-boot.
Maybe we should introduce the ldlVersion into the _meta property so that the boot code can tell which format the json conforms to.
I have considered that too, but since we are able to distinquish 1.x and 2.x even without an explicit version field, I'd rather defer adding that field until it is truly needed.
from loopback-boot.
There was no activity for almost a month, I am closing the issue. Feel free to reopen if needed.
from loopback-boot.
I am having this issue, is there simply a way to explicitly pass model-config.json to
boot(app, {})
?
Something like:
boot(app, {
modelConfig: require('some-custom-file.json')
})
I am looking at the current docs for this:
https://apidocs.strongloop.com/loopback-boot/
and am not quite seeing it
from loopback-boot.
Also, just an aside, in the boot documentation, it's not clear to me what the difference is between model configuration and model definitions:
[models] Object
Object containing Model configurations.
[modelDefinitions] Array
List of model definitions to use. When options.modelDefinitions is provided, loopback-boot does not search filesystem and use only the models provided in this argument.
anybody care to explain? thanks!
from loopback-boot.
from loopback-boot.
what the difference is between model configuration and model definitions
In short: model configuration is the data in server/model-config.json
, model definition is the data from common/models/{name}.json
(see also #27 (comment))
from loopback-boot.
Related Issues (20)
- Subfolders in boot folder HOT 7
- [forward-port] Fix resolution of middleware modules
- Boot scripts are loaded, but not actually run HOT 9
- organizing configuration files leads to problems HOT 3
- test failing on browserify due to form-data HOT 1
- Document refactored design of loopback-boot HOT 1
- datasources duplicated when booting using a config HOT 1
- models not loaded when using config on boot HOT 1
- 3.0.0
- Async boot scripts - silent failure with security risk HOT 6
- resolveAppScriptPath() is not pass scriptExtensions to fixFileExtensions() HOT 2
- [BUG] Middleware is loading .js.map of .js HOT 1
- The middleware "loopback#static" in phase "files"is not defined in the main config
- Async operations in component initialization HOT 3
- isomorphic and uglify causing "AssertionError: must provide a valid {{SharedClass}}" HOT 1
- custom middleware not found when boot options are just __dirname HOT 2
- Why next() requires to trigger process.nextTick in bootscript. HOT 2
- export-api-def doesn't work with loopback-boot@3 HOT 1
- Address usage of config/application on boot LBOptions HOT 2
- Loopback-boot updating to 3.3.1 producting "LoopBack server listening @ https://undefined:undefined/" HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from loopback-boot.