3. Editing structure

• Model and Database
• Working Independently of the Database
• Multiple Database Environments
• Project
• Connections
• Undo and Redo

OrmFactory is a database model editor. It allows you to work with a database structure as a model independently of the actual database.

The model can be changed without immediately changing the database. This makes it possible to design and modify database structures locally, review the changes, and synchronize them with a database when appropriate.

Visually, the project structure can be seen in the project explorer.

Model and Database

The Project Model describes the database structure that you are working with.

A database in the model contains schemas, and schemas contain tables:

Database
└── Schema
	└── Table
		├── Column
		├── Primary Key
		├── Foreign Key
		├── Index
		└── ...

The model can contain information that comes directly from the database as well as information used only by OrmFactory.

For example, a table can contain:

• columns and their database types;
• primary keys;
• foreign keys;
• indexes;
• unique constraints;
• comments;
• generated names such as ClassName or FieldName;
• virtual foreign keys;
• other model metadata.

See 3.3. Table editing for details about editing tables and their contents.

Working Independently of the Database

The model and the actual database are separate.

When you change the model, OrmFactory does not automatically modify the database structure. Instead, the model becomes different from the current database structure.

For example, you can add a column to a table in the model:

Model
└── Users
	├── Id
	├── Name
	└── Email

while the actual database still contains:

Database
└── Users
	├── Id
	└── Name

This allows you to make and review structural changes before applying them to a database.

If an active database connection is available, OrmFactory can synchronize the database with the model.

See 3.4. Synchronization for details.

Multiple Database Environments

Keeping the model separate from the database is particularly useful when the same logical database exists in multiple environments.

For example:

Production
Development
Local
Test

The model can be modified locally and then synchronized with the appropriate database environments separately.

This means that the database used during development does not have to be modified every time the model is edited.

Project

The complete model and its associated project resources are contained in an OrmFactory Project.

A project may contain multiple database models as well as layouts, connections, generators, and profiles.

The logical structure of a project is described in Project structure.

The way this project is stored on disk is described in Project file format.

Connections

A Connection describes how OrmFactory connects to a Database.

There are two types of connections:

• Project connections are part of the project and can be shared with other users.
• Local connections are stored separately in the user's local documents and are not part of the project.

A project stores project connections, but never stores local connections.

Project connections can be used by profiles and are therefore part of the project's shared configuration. Local connections are intended for connection information that should remain specific to a particular user's environment.

A connection contains common connection properties such as:

• database type;
• server host;
• server port;
• user name;
• password;
• database name;
• optional SSH connection information.

Some database types have additional connection properties.

A Connection belongs to a Database in the project model. It describes how OrmFactory accesses that Database; it does not define the database model itself.

Undo and Redo

Because OrmFactory works with a local model, changes to the model can be maintained in an undo/redo history.

You can undo or redo changes made while editing the project.

This includes changes such as:

• adding, removing, or modifying tables and columns;
• changing keys and indexes;
• moving tables in a layout;
• creating or deleting layouts;
• synchronizing the model with a database;
• other changes to the project model.

Undo and redo operate on the model, not directly on the database.

When a change is sent to a database, OrmFactory cannot undo that database operation through the model's undo/redo history.

For example, if a table is changed in the model and the change is then synchronized with the database, undoing the model change restores the previous model state. It does not automatically execute an inverse SQL operation against the database.

You can subsequently synchronize the restored model with the database. Depending on the change, this may result in the corresponding database change being reversed.

This separation allows the model to remain the source of the structure being edited while database changes are applied explicitly through synchronization.

---