Mount names

Entities, objects, operations, and queries have mount names:

• for entities and objects, those names are the SQL table names where the data gets stored
• for operations and queries, you use a mount name to invoke an operation or a query from the outside

By default, you define a mount name by a fully qualified name of a definition.

Example

namespace foo {
    namespace bar {
        entity user {}
    }
}

note

The mount name for the user entity becomes foo.bar.user, reflecting its hierarchical position.

Custom mount names

You can use the @mount annotation to specify a custom mount name. You can specify the @mount annotation for entities, objects, operations, and queries.

Syntax: @mount('desired_mount_name')

Example

@mount('foo.bar.user')
entity user {}

Entity attributes

Since 0.15.1, you can apply @mount to an entity attribute, where it names the database column that stores the attribute. This lets you rename an attribute in code while keeping the existing column and its data:

// existing deployment
entity user { fname: text; age: integer; }

// rename without data loss
entity user {
    @mount('fname') first_name: text;
    age: integer;
}

No schema changes are performed. The column fname continues to store the data and is accessed as user.first_name in code. Keys, indexes, metadata, and size constraints are generated using the mapped column name, so database initialization no longer drops or recreates columns during such renames.

Mounting namespaces

Prefix elements within a namespace with a custom mount name.

Example

@mount('foo.bar')
namespace ns {
    entity user {}
}

The resulting mount name for user is foo.bar.user.

Mounting modules

Prefix elements within a module with a custom mount name.

Example

@mount('foo.bar')
module;

entity user {}

The resulting mount name for user is foo.bar.user.

Nested namespace mounts

When @mount is applied to a namespace or module, elements inside inherit the mount context. Nested elements can then define mount names relative to this context. For example, when defined in a namespace:

Example

@mount('a.b.c')
namespace ns {
    entity user {}
}

The entity user has the following mount names when annotated with @mount:

• @mount('.d.user') -> a.b.c.d.user
• @mount('^.user') -> a.b.user
• @mount('^^.x.user') -> a.x.user

Relative mount name shortcuts

Construct complex mount names relative to context using special characters:

• . (dot): Appends names to the current context mount name.
• ^ (caret): Removes the last part from the context mount name.

@mount("foo.")
entity user {
}

// mount name = "foo.user"

@mount("foo")
entity user {
}
// mount name = "foo"

Import behavior

Mount names are set at the point where entities, objects, operations, and queries are defined, not where they are imported. Importing a module into a namespace with a different mount name does not change the mount names of the imported definitions.

// snapshots.rell
@mount("eif.snapshots")
module;
entity my_entity {}

// hbridge.rell
@mount("foo")
namespace bar {
    import ^.eif_snapshots.*;
}

The my_entity will have mount name eif.snapshots.my_entity regardless of where it's imported.

Special operations

Special operations require the __ prefix in their mount names. Use dot notation for consistency with Rell conventions:

// ✅ Preferred: Use dots for mount names
@mount('icmf.message')
operation __icmf_message() {}

@mount('stork.oracle.prices')
operation __stork_oracle_prices() {}

// ❌ Avoid: Using underscores in mount names
// @mount('icmf_message')
// operation __icmf_message() {}

note

The __ prefix is required for all special operations and must be explicitly written. It is recognized by Postchain to denote lifecycle hooks and reserved operations.