Modules v2 allows you to build a self-contained Ninox database that shares selected data and logic through a module interface. As your application grows, this interface may evolve - new fields are added, calculations change, relationships are updated, and shared logic becomes reusable across databases.

Modules v2 supports this evolution through versioned interfaces, schema resynchronization, and global function mapping. This allows module providers and consumers to adapt to change without breaking existing connections.

A module interface is not a static setup. It is a public contract between databases that can grow over time in a controlled way.

Interface updates and versioning

A module interface defines which tables, fields, relationships, calculated fields, and global functions are exposed. When a provider changes the exposed structure, a new version of the interface becomes available.

Consumers connected to that interface can decide when to apply the update. This gives teams more control over rollout and reduces the risk of disrupting productive systems unexpectedly.

Versioning ensures that updates remain visible, traceable, and manageable.

The module interface is the public contract between a source database and connected target databases. From here, you define the interface ID and choose which public fields and global functions to expose.

Out-of-sync interfaces after module changes

When a module interface changes, errors can occur if the updated interface is not yet synchronized between the source and connected target databases.

This can happen on both sides:
in the target database, if it is still using an older version of the interface
or
in the source database, if the interface was updated but the changes have not yet been synced to connected targets

Typical examples include:

·       a field is added or removed

·       a table is removed

·       the structure of a table change

If the interface is out of sync, users may see an error like this:

Example of an error caused by an outdated or unsynchronized interface.

What this means: one side is referring to a field or table definition that is no longer aligned with the current interface structure.

For example, if a new field is added in the source interface but the updated interface has not yet been synced to connected targets, an error may also appear on the source side when trying to add data to that new field.

To resolve the issue, update the module interface and make sure the latest version is synchronized between the source and all connected targets.

In the target database, the interface can be updated here:

Update the connected module in the target database to align it with the latest version of the source interface.

After the update and synchronization, the source and target databases use the same interface structure and data can be edited as expected again.

Interfaces are not updated automatically by default. This is intentional, because some users may choose to remain on an older version until they are ready to apply the changes.

Schema resynchronization

When a consumer applies an interface update, Ninox performs a schema resynchronization.

During this process, newly exposed fields can be reviewed and mapped, removed elements are clearly indicated, and existing mappings are preserved where possible. Relationships and dependencies are validated so that the updated structure remains consistent.

Schema resynchronization makes it possible to evolve shared structures without disconnecting and rebuilding the module connection.

Sharing logic across databases

Modules v2 also supports reusable business logic through global functions.

A provider can expose global functions through the interface so that consumers can call shared logic directly instead of recreating it locally. This reduces duplication, improves consistency, and allows business rules to remain centralized.

Together, interface versioning and shared logic make modules more than a data-sharing feature. They become stable building blocks for scalable system architecture.

A provider database can expose multiple interfaces, which consumers integrate as synchronized local copies in their own schema.