Skip to main content

CREATE SHARED (bSQL) | Blockpoint Docs

Creates a shared relationship between the created blockchains, and the existing blockchains specified. For examples, see Examples.

bSQL Syntax Conventions

Simple Syntax​

-- Simple CREATE SHARED Syntax
CREATE SHARED
    { shared_arg, shared_arg [ ,...n ] }

<shared_arg> := { database_name.blockchain_name |
     blockchain_name |
     create_blockchain_statement }

<create_blockchain_statement> :=
                { database_name.blockchain_name | blockchain_name },
                <blockchain_type>
                ( { <column_definition> } [ ,...n ] )
                 [ INDEX <index_definition> [ ,...n ] ]

Arguments​

database_name
The name of the database in which the shared blockchain is created. database_name must specify the name of an existing database and must be consistent throughout the statement. If not specified, database_name defaults to the current database.

blockchain_name
The name of a blockchain currently existing in the database to be shared with its siblings.

create_blockchain_statement
The blockchain to be created and shared, see CREATE BLOCKCHAIN for full syntax.

Remarks​

  • Shared blockchains share a primary key index.
  • Shared blockchains of types TRADITIONAL and SPARSE additionally share a lifetime index.
  • The first blockchain in the shared relationship is referred to as the parent, and all subsequent blockchains are referred to as children. The parent of a shared relationship is the oldest existing blockchain in the shared relationship (if specified), or the leftmost blockchain created in the statement.
  • If a shared blockchain relationship is desired it is recommended to create and share the blockchains simultaneously using the statement above, instead of creating and sharing. This limits the mutations done to the system tables.

Limitations​

  • HISTORICAL blockchains can't be shared.
  • HISTORICAL PLUS can only be shared with other blockchains of the same type.
  • Blockchains can only be shared if they have the same primary key data type.
  • Shared blockchains have primary keys that are unique across all the parent and all its siblings.
  • If existing, non-empty blockchains are shared and don't satisfy the unique requirement an error is returned.
  • Auto-Incremented primary keys are only allowed when the shared statement doesn't include existing blockchains. The primary key is auto-incremented across blockchains.

Permissions​

MANAGEMENT permissions required on the database.

MANAGEMENT permissions on the database default to members of the admin fixed database role. Members of the admin role can transfer permissions to other users.

Examples​

A. Creating shared blockchains.​

The following example creates two blockchains dev_employees and sales_employees that share a primary key.

CREATE SHARED dev_employees HISTORICAL PLUS
 (devid UINT64 PRIMARY, firstname STRING PACKED, lastname STRING PACKED),
        sales_employees HISTORICAL PLUS
 (salesid UINT64 PRIMARY, firstname STRING PACKED, lastname STRING PACKED)

B. Sharing existing blockchains.​

The following example uses alters two existing blockchains in the internal by joining them into a shared relationship.

CREATE SHARED internal.dev_employees, internal.sales_employees

C. Sharing created blockchains with existing blockchains.​

The following statement uses the parent blockchain dev_employees, and creates and promotes the sibling sales_employees to a shared relationship with the parent blockchain.

CREATE SHARED internal.dev_employees, 
    sales_employees HISTORICAL PLUS
     (salesid UINT64 PRIMARY, firstname STRING PACKED, lastname STRING PACKED)

See Also​