States and Stateflows
In the real world, every person, place and thing moves through a flow of States (called Statuses in the application) or Stateflow. A State is like a stage, phase, or step. For example, possible States for a fund might be: proposed fund, being funded, fully funded, closed, or retired. A University student moves through several States during her time as a student. Every Object will be in one State for every Class it belongs to and the Object’s State history is automatically logged in the database.
An Object can belong to multiple Classes. When this is the case, the Object has a current State, and State history, for each of the Object's Classes. How States work with Object Multi-Class is particularly useful because a person can be a current active customer, a retired employee, and a prospective board member. For example, a company can be both a startup, and, perhaps because they have extra space, they also allow other small businesses to share their space.
GroverDB tracks not only the current State of every Object, but it also tracks the history of all the previous States. This is useful for seeing how an Object got to where is it today.
For every Class, States and the possible flow from State to State, must be defined.
States are very important to the design of the database. For instance, Connection rules are based on the Object’s State. Applying Connections based on States is one way that GroverDB eliminates the need for programming code.
Users can easily Filter, Browse, and Analyze Objects and their data based on State.
States have several properties that help define the behavior of GroverDB:
- Default State: When a new Object is created, or a new Class is added to an existing Object, the default State is normally the initial State.
- Inactive: A State that is flagged as inactive will be disabled in the Browse selection until it is toggled on by the user. This is useful for automatically not including some States (e.g. deceased or Inactive) in user searches.
- State Flow Universal: An Object may be set to this State without a pre-defined State flow path. This is useful for States that are outside a strict flow.
- Retired: An Object may not be set to a State that is retired, but the Object history of the State remains in the database.
States and Stateflows are inherited just like Attributes.