Open JerryNixon opened 1 year ago
The following behavior is not really hot-reload. While probably way easier to implement, this just saves a dev the few seconds from having to hit ctrl + c
and run dab start
For development it is not important that the engine hot reload and just restarts
The following behavior is not really hot-reload. While probably way easier to implement, this just saves a dev the few seconds from having to hit
ctrl + c
and rundab start
For development it is not important that the engine hot reload and just restarts
I agree, and am wondering, aside from ease of implementation, if there is some benefit to restarting the engine this way, since you could do this yourself so easily.
?. Is "restart the engine" too drastic? Is there a simpler way to do the development version?
Yes, restart engine seems unnecessary. That is NOT same as hot reload, why don't we keep it simple - just hot reload(refresh the engine only for the properties the mode supports the refresh?
?. Can we/should we implement the production version of this first?
It was agreed upon previously that development
version would be implemented first.
If the requirement is now changing, we will NOT undo what we have implemented already for the development
version but consider pivoting towards completing the production scenario first in future after finishing off whatever is in progress for development
?. Should runtime.hot-reload-enabled also be hot reloadable in production?
Since we are only enabling hot reload of the loglevel in production, I think it should be fine to hot reload the runtime.hot-reload-enabled
option itself, since even after enabling this - only loglevel can be reloaded.
What happened?
For reference: #67
Hot reload
The idea of hot reload allows the direct manipulation of the
dab-config.json
file without requiringdab start
.Use cases
mode=development
allow a simpler workflow so developers can tweak the configuration file.mode=development
allow administrators to modifyminimum-log-level
to diagnose problems.Canges
Config:
runtime.hot-reload-enabled=true|false
defaulttrue
.When set to
true
, depending onmode
the hot reload behavior will respond to changes in thedab-config.json
file.CLI:
dab start --hot-reload-enabled true
When set to
true
, depending onmode
the hot reload behavior will respond to changes in thedab-config.json
file. If the same property is set to a conflicting value in the config file, the CLI value overrides it.Config:
runtime.minimal-logging-level=information|enum
default based onmode
.Currently only available as an argument in
dab start
this allows in-memory modification through hot reload.mode=Production
is the primary use case, allowing increased (or decreased) logging during troubleshooting.Order of precedence In terms of precedence of value, the last thing that sets the log level wins.
mode
mode=Production
thenInformation
mode=Development
thenDebug
config
then ignore themode
-based default.CLI
then ignore the `config setting, except...minimal-logging-level
is set by hot reload then ignore current in-mem setting for hot reload value.Behavior
production
it is important that the engine hot reload and not restartsdevelopment
it is not important that the engine hot reload and just restartsSome questions
?. Should
runtime.hot-reload-enabled
also be hot reloadable inproduction
? ?. Can we/should we implement theproduction
version of this first? ?. Is "restart the engine" too drastic? Is there a simpler way to do thedevelopment
version?Version
Future
What database are you using?
Azure SQL
What hosting model are you using?
Local (including CLI)
Which API approach are you accessing DAB through?
REST, GraphQL
Relevant log output
No response
Code of Conduct