Skip to main content

Object owner

Each object in a FairCom server has an owner. Owners have full control over their objects and objects exist independently in their owner’s space.

Owner privileges

Each database object has an owner, which is an account with full administrator privileges on that object.

Objects created by the system are owned by the admin account.

Allowing an account to own an object has several benefits.

  • You may create objects for your personal use and have complete control of them.

  • An application account may create objects so it can later alter and delete them.

  • An administrator may create objects so that no other account can have administrative permissions for those objects.

Owner Space

The full name of an object includes the names of its database, owner, and object itself. The database and owner names define an object namespace, which allows an object with the same name to exist in different databases and owner spaces. 

In SQL databases, an “owner space” is called a “schema”.  FairCom uses the word “schema” to refer to a JSON schema that defines data rules for the structure of a JSON document.

There are several reasons that the full name of an object includes its database and owner:

  • You can store an object with the same name in different databases and owner spaces.

  • You can make point-in-time copies of tables in your owner space to troubleshoot issues, test table changes, test data changes, and so forth.

  • You can write a query using just the object name and run it unchanged in different databases and owner spaces, such as running the same query in development, test, stage, and production databases.

Default owner name

The default owner name used in JSON action APIs is represented by the “defaultOwnerName" property in the "createSession" and "alterSession" actions. Its value helps define the owner of objects you create in the session.

If you do not set the “defaultOwnerName" property when you create a session, the server assigns the "defaultOwnerName" to the username of the account that created the session.

In each JSON action, if you apply an account username to the "ownerName" property, the server makes that account the owner of the object. If you omit the "ownerName" property, the server uses the “defaultOwnerName" value you set when you create or alter the session. 

If you do not set a value for “defaultOwnerName", the server uses the username of the account that created the session.

There are several benefits to this approach:

  • When you want the logged-in account to own the objects it creates, do not set the “defaultOwnerName" and “ownerName" properties in JSON actions.

  • When you want to create objects owned by another account, create or alter a session and set the “defaultOwnerName" property to the other account’s username or omit the “ownerName" property in each JSON action request and the server will use the value you assigned to the “defaultOwnerName" property.

  • When you want to create an object that is owned by a specific account, set the “ownerName" property to that account's username.