Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

In a LiteFarm deployment, the database runs as litefarm-db, a Docker container built from the official Postgres image.

Auto-Increment ID Conventions as of August 2024

In our migration strategy:

  • Manually Set IDs: Used for the permissions table to ensure consistent IDs across different environments (local, beta, production).

    • Previously, hard-coding IDs led to "UniqueViolationError" issues when inserting new rows.

      • #2857 (comment)

      • Jira Legacy
        serverSystem Jira
        serverId815f41e5-e5fb-3402-8587-82eccc3ffab0
        keyLF-3651

  • Auto-Increment IDs: Applied by default unless there's a specific reason to manually set IDs. This helps avoid conflicts and simplifies record management.

The API code

An Application Programming Interface (API) is an interface that a software product provides for use by other software, rather than by human users.

...

Code Block
languagejs
/**
 * Models data persistence for users' notifications.
 */
class NotificationUser extends baseModel {
  /**
   * Tracks open subscription channels for server-sent events. To support multiple sessions by the same user,
   *   keys are user IDs; values are Maps with timestamp keys and HTTP response object values.
   * @member {Map}
   * @static
   */
  static subscriptions = new Map();

  /**
   * Identifies the database table for this Model.
   * @static
   * @returns {string} Names of the database table.
   */
  static get tableName() {
    return 'notification_user';
  }

  /**
   * Identifies the primary key fields for this Model.
   * @static
   * @returns {string[]} Names of the primary key fields.
   */
  static get idColumn() {
    return ['notification_id', 'user_id'];
  }

  /**
   * Supports validating instances of this Model class.
   * @static
   * @returns {Object} A description of valid instances.
   */
  static get jsonSchema() {
    return {
      type: 'object',
      required: ['user_id'],
      properties: {
        notification_id: { type: 'string' },
        user_id: { type: 'string' },
        alert: { type: 'boolean' },
        status: {
          type: 'string',
          /**
           * @name userNotificationStatusType
           * @desc Enumerated type for user notification status.
           * @enum
           * */
          enum: ['Unread', 'Read', 'Archived'],
        },
        ...this.baseProperties,
      },
      additionalProperties: false,
    };
  }

  /**
   * Defines this Model's associations with other Models.
   * @static
   * @returns {Object} A description of Model associations.
   */
  static get relationMappings() {
    return {
      notification: {
        relation: Model.BelongsToOneRelation,
        modelClass: Notification,
        join: {
          from: 'notification_user.notification_id',
          to: 'notification.notification_id',
        },
      },
    };
  }

  // other custom methods not shown here.
}

...

  • tableName() tells Objection the database table name for this model

  • idColumn() indicates the table columns needed to uniquely identify a table row

  • jsonSchema() supports validating the data contents of class instances before database modifications are made. Objection uses the embedded information to determine the appropriate data types, which values are required to be present, etc.

  • relationMappings() describes how this model is related to others. Each instance of this class belongs to one instance of the Notification model class.

  • templateMappingSchema() (not shown) this is a custom function created by LiteFarm to define how one would treat properties and relations of the models graph in a duplication context (example: repeat management plans)

In jsonSchema(), the spread syntax expression ...this.baseProperties is used to include the base model's "base properties" in validating instances of class NotificationUser. These properties are "bookkeeping" columns found in most LiteFarm database tables. They record who created the row, and when; who last updated the row, and when; and whether the row is marked as "deleted". (In most cases, LiteFarm performs "soft deletes"; rather than actually deleting a database row, the row is marked as deleted, and excluded from further use.)

...