How can i exclude the specific model from auto-migration.

[satishverma143]

How can I exclude the specific model from auto-migration in sails v1.0 I have tried to add migrate: 'safe' in the model. but it's not working.

Node version: v10.15.3 Sails version (sails): 1.0.0 ORM hook version (sails-hook-orm): 2.0.0-16 Sockets hook version (sails-hook-sockets): 1.4.0 Grunt hook version (sails-hook-grunt): 3.0.2 DB adapter & version (e.g. sails-mysql@5.55.5): 1.0.1

---

[sailsbot]

@satishverma143 Thanks for posting! We'll take a look as soon as possible.

In the mean time, there are a few ways you can help speed things along:

• look for a workaround. (Even if it's just temporary, sharing your solution can save someone else a lot of time and effort.)
• tell us why this issue is important to you and your team. What are you trying to accomplish? (Submissions with a little bit of human context tend to be easier to understand and faster to resolve.)
• make sure you've provided clear instructions on how to reproduce the bug from a clean install.
• double-check that you've provided all of the requested version and dependency information. (Some of this info might seem irrelevant at first, like which database adapter you're using, but we ask that you include it anyway. Oftentimes an issue is caused by a confluence of unexpected factors, and it can save everybody a ton of time to know all the details up front.)
• read the code of conduct.
• if appropriate, ask your business to sponsor your issue. (Open source is our passion, and our core maintainers volunteer many of their nights and weekends working on Sails. But you only get so many nights and weekends in life, and stuff gets done a lot faster when you can work on it during normal daylight hours.)
• let us know if you are using a 3rd party plugin; whether that's a database adapter, a non-standard view engine, or any other dependency maintained by someone other than our core team. (Besides the name of the 3rd party package, it helps to include the exact version you're using. If you're unsure, check out this list of all the core packages we maintain.)

  ---

Please remember: never post in a public forum if you believe you've found a genuine security vulnerability. Instead, disclose it responsibly.

For help with questions about Sails, click here.

[whichking]

Hey, @satishverma143!

The migrate model setting can actually only be set in config.models.js as an app-wide default. Although this behavior isn't currently expressed in the documentation, it is expected. Here's the PR that adds that language to the docs.

You might find the discussion on this related GitHub issue to be of some use.

[Lovinity]

@whichking

I fail to understand why the constraint.

Here is a use case where it is necessary to have model-specific migration settings: I have a Sails application that not only uses its own database but shares use of a database with a separate non-Sails application (this is necessary functionality for the Sails app to do as it was intended; the other app's API is not robust enough to access everything I need to without directly using the database. As the other app is closed source, I cannot change this.). It should be able to migrate its own database, but I should force migration to safe on the database used by the other application (otherwise the other application stops working).

Here is potential desired functionality to conform with safety standards for production:

• Migration settings are accepted per-model. But the merging of the migrate property from config/models.js, config/custom.js, config/local.js, config/env/production.js, etc, does not work as normal for other settings. Instead, it is based on priority.
• If ANY valid config requests migrate safe, then ALL applicable models within the config's scope run migrate safe (e.g. if config/env/production.js specified migrate safe, then all models are migrate safe in production even if a specific model requests migrate alter or drop).
• If any config requests migrate alter, this overrides all configs with migrate drop within its scope, but is overridden by migrate safe.
• migrate drop is always overridden by any other config within the same scope that requests migrate alter or migrate safe.

[DominusKelvin]

Hey @Lovinity in production migration is always set to safe. Doesn't this work for your use case?

[Lovinity]

Hey @Lovinity in production migration is always set to safe. Doesn't this work for your use case?

It works in production. But say I, or a future engineer, need to re-create or alter the database for the Sails app by running in development. If Sails has models for a database shared with another application, those models (tables) will get modified by migration, which is undesired and may cause the other application to stop working. There is no other way to do this in my use case; I would ideally use an API to communicate with the application instead of directly in the database. Unfortunately, the API for the other application does not have enough coverage. So I'm forced to work with the database directly.