Most hof app commands are run from the application directory. The following commands are used in the application lifecycle.

Application Lifecycle

Deploy, Shutdown
hof app deploy
hof app shutdown
Moving code
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

Database Lifecycle

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

  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>

and finally

hof app push

See the more advanced section for further details.

Complex changes

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

  1. create new field
  2. migrate database
  3. transform data
  4. delete old field
  5. 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.

Function Lifecycle

coming soon