I'm looking to access control example. https://github.com/strongloop/loopback-example-access-control
It says we need to put sample-models.js file under server/boot folder. That means, everytime I run the application, the creation process will be made again and again. Of course, I'm getting errors on the second call.
Should I put my own mechanism to disable if ones it run, or is there a functionality in loopback?
Bot scripts are for setting up the application. And run once per application start.
So if you want to initialize database or any initializing which would be persisted by running boot script, you need to check if it is initialized first or not.
For example for initializing roles in db, you need to check if there is desired roles in db or not. And if there is not, so create ones.
There is no other functionality in loopback for this.
Related
I've hosted my app in Google Cloud Run, a simple Vue's frontend connected to a django API. The problem arises when I try to set maintenance mode to the API, protecting it from unexpected calls. For this purpose I've used django-maintenance-mode's package, but, as I said, due to the implicit stateless character of GC Run, the enviroment variable that stores the maintenance mode's value drops when there isn't any active instance, getting back to OFF.
I'd like to know any other possible solution or fix overriding any of this package's methods to make it work in my project.
Thanks in advance!!
You can use the Graceful shutdowns which will allow you to capture the environment variable that stores the maintenance mode value. Once the value is captured you can store it in a database (Cloud SQL) or in a file on Cloud Storage. At each startup, you get the last value.
To elaborate, we have one server we have setup to run django. Issue is that we need to establish "public" test server that our end-users can test, before we push the changes to the production.
Now, normally we would have production.domain.com and testing.domain.com and run them separately. However, due to conditions outside our control we only have access to one domain. We will call it program.domain.com for now.
Is there a way to setup two entirely separete django intances (AKA we do not want admin of production version to be able to access demo data, and vice versa) in such a way we have program.domain.com/production and program.domain.com/development enviroments?
I tried to look over Djangos "sites"-framework but as far as I can see, all it can do is separate the domains, not paths, and it has both "sites" able to access same data.
However, as I stated, we want to keep our testing data and our production data separate. Yet, we want to give our end-user testers access to version they can tinker around, keeping separation of production, public test and local development(runserver command) versions.
I would say you use the /production or /development path to select which database to use. You can read more about multitenancy from here https://books.agiliq.com/projects/django-multi-tenant/en/latest/
As title says, I have small web app, without using database and models.
I'd like interface to change some of Flask own config parameters, and thought that flask-admin may bring me there quickly. Is this easily possible?
You can't generally change configuration after starting the application without restarting the server.
The application (at least in production) will be served with multiple processes, possibly even on multiple servers. Changes to the configuration will only effect the process that handled the request, until the other processes are reaped and re-start. Even then, they may fork from a time after the configuration was read.
Extensions are not consistent about how they read configuration. Some read the configuration from current_app every request. Some only read it during init_app and store their own copy, so changing the configuration wouldn't change their copy.
Even if the configuration is read each time, some configuration just can't be changed, or requires other steps as well. For example, if you change databases, you should probably make sure you also close all connections to the old database, which the config knows nothing about. Another example, you could change debug mode but it won't do anything, because most of the logging is set up ahead of time.
The web app might not be the only thing relying on the configuration, so even if you could restart it automatically when configuration changed, you'd also need to restart dependent services such as Celery. And those services also might be on completely different machines or as different users.
Configuration is typically stored in Python files, so you'd need to create a serializer that can dump valid Python code, or write a config loader for a different format.
Flask-Admin might be able to be used to create a user interface for editing the configuration, but it wouldn't otherwise help with any of these issues.
It's not really worth it to try and change Flask.config after starting the application. It's just not designed for that. Design a config system specifically for the config you need if that's something you need, but don't expect to be able to generally change Flask.config.
In our Sitecore project we have set a manual policy for indexing. We need to copy the indexes after the build to other servers. I know how we can copy the files from one server to another. So my question is:
How can I set a tool to run when the index rebuild is finished? Is this even possible?
We don't want do run the tool manually after each run.
You can call code when certain events have started or finished.
In your case, one option is for you to hook into the indexing:end handler to start an xcopy command for instance - or call your tool programmatically from there.
Is there a reason why you can't keep the indexes up-to-date on the servers themselves?
I have a problem in understanding the relationship between services and registry.
I have the task of taking my windows C++ program and transform it from simple application to a service.
I read that I need to produce some more functions as: start stop resume install.
The problem is:
Why I need the regisrty ?
how I enter the new program ?
Beside those method what I need to do with the registry? how I enter inside it ?
Do I need to write a script for entering the service ?
I read but I just didn't understand, any answear and or some good links to explanation will be appreciated.
Thanks,
I'm not aware of any documented relationship between services and the registry. Services can use the registry to store their settings, just like any other application, but they're not required to.
Formally, you don't need the registry. You simply need to install the service using the relevant API functions. As part of their implementation, the API functions create registry entries that the OS uses later to know when and how to start your service, but I don't think those keys are documented with any expectation that developers would modify them manually, so don't worry about them.
If your program uses the registry to store settings, though, you'll need to understand what account your service runs as, because that affects what areas of the registry your program has access to.
Install your service by calling CreateService. Do that in your program's installer. You can also make your service install itself when it detects itself being run with a certain command-line switch, such as -i. To uninstall your service, call OpenService and then DeleteService. In either case, you'll need to call OpenSCManager first. See MSDN for more on how to call those functions.
Alternatively, you can use the sc command to create and delete your service.
As I mentioned above, you don't need to do anything with the registry. Just install and uninstall your service with the API and let the OS take care of the rest.
You don't need to write any scripts to start your service. The OS already knows how to start it (because it's installed). If your service is something that users would want to start and stop frequently, then rather than use the service control panel then they can use the net or sc commands.
We use the registry to store command line parameters. The executable is passed a special parameter saying "you are a service, and here is your service name", and then the program knows to look in the registry and read the rest of the command line parameters from there. Honestly, I don't know why it was done this way, but I suspect that there's a limit on the length of service command line.
As Rob said however, services don't have to use the registry at all.