hof app commands are run from the application directory.
The following commands are used in the application lifecycle.
hof app deploy hof app shutdown
hof app push hof app pull
Note, push and pull do not require the application to be deployed.
Updating to a new Studios version
hof app update "<version>"
Resetting the application
hof app reset
When you change the data model within your types you will need to run a database migration.
note this is not all changes, the following, and maybe some undocumented ones
type: owned: ... visibility: ... fields: ... relations: ...
Update the development database
While developing, you will be changing the shape and relations of you data and models. To make your development server match the latest state you desire, run:
hof db reset
Create a checkpoint
When you are ready to update your production, user facing server, you will create a checkpoing. To create a checkpoint for your This will create a new set of migrations and move the “latest” to the current state.
hof db checkpoint
Now, when you reset, the database is reset to this point. This will overwrite the database with the seed data and should nly be sued in development.
The checkpoint command will not effect your data. It will only make the outstanding migrations and create a new point where reset works from (in development).
Completely reset the database
hof db reset --hard
This will reset the tables, migration history, and restore to the current desired state with seed data.
Renaming fields and other design
Renaming fields and other design paths often requires adding a “rename” field.
... name: <old-name> rename: <new-name>
Then, do the app and database updates:
hof app push hof db checkpiont
(this gets harder with development, and the interaction or replication with / for production. More notes and documentation needed)
and then making then name the new name.
... name: <new-name>
hof app push
See the more advanced section for further details.
Changing the type of a field, possibly with the name as well, can create changes which would destroy existing data. In these cases, it is often better to
- create new field
- migrate database
- transform data
- delete old field
- migrate database
As we find more of these cases, we will add extra configuration and transformations to enable the process to become more smooth.
Please reach out to us if you are engaging is any complex use-cases.