![]() I don’t have permission to drop those views, nor would I want to. For instance, I’ve been granted access to an HR employee view of a database I don’t administer. I have models that are simple ORM interfaces to database views. I don’t want to discount the concerns and complications previously mentioned, but the migration strategy should be a per-model setting. Ideally, though, setting the strategy in the adapter is still too wide. This feature should only build on that use the strategy added to the adapter, if specified. That’s the current behavior and nothing to deprecate. ![]() It seems like there should be a default (app-wide) migration strategy if one isn’t specified. I’m not sure why this would be a breaking change. My two cents - thanks for your consideration and happy Thanksgiving :) It is going to be too much of a burden to use Sails to develop applications that need data from external systems via waterline adapters. I feel like dropping support for this feature undermines the benefits of the adapter-based approach of waterline. And for any relational databases I want to use, I have to manually create all the tables. However, if I need to use a datastore that is read-only (say, to integrate data from an external system), without being able to specify migration strategies per model (or at least per datastore) I can no longer use the migration feature of sails.Īlso, I can no longer use the sails-disk adapter for quick-rev development since I can't really manually migrate models with sails-disk. Sails/Waterline is awesome because it provides an adapter specification (and generator) so that I can integrate these different datastores into my applications and interact with them using the sails model APIs. In most real life situations, an application is going to need to interact with more data sources than just the core CRUD models, eg. ![]() Here is my case why you should consider supporting it: I could certainly be misunderstanding something, but this appears to be a breaking I did see that note in the docs, but I thought it was just a suggestion. I've modified my initial repo to include another puppy/kitten app generated with Sails v0.12.9 to demonstrate this. In Sails v0.12.9 I was able to have a different migrate setting per each model - this was very helpful when I had different models using different connections (datastores) that may or may not be read-only. It can only be set as an app-wide default in. However, in Sails v1 this is not the case - the migrate setting cannot be set on a per-model basis. They can be specified on a per-model basis by setting top-level properties in a model definition, or as app-wide defaults in. Model settings allow you to customize the behavior of the models in your Sails app. My confusion is not about what the different migration strategies do, but rather why Sails no longer supports migrate as a top level model property.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |