Skip to main content

​
Introduction to the label_formats Table

The label_formats table is designed to store and manage information about label formats for components in the Serial application. This table plays a crucial role in the system by providing a centralized repository for label specifications, including dimensions, metadata, and XML representations of label designs.

​
Table Structure

The label_formats table is structured to capture comprehensive details about each label format. Here’s a detailed breakdown of its columns:
Column NameData TypeConstraintsDescription
iduuidprimary keyUnique identifier for the label format
company_iduuidnot null, foreign keyReference to the company owning the label format
component_iduuidnot null, foreign keyReference to the component associated with the format
namevarchar(255)not nullName of the label format
widthfloatnot nullWidth of the label in millimeters
heightfloatnot nullHeight of the label in millimeters
displayed_size_unitvarchar(10)check (in (‘MM’, ‘IN’))Unit for displaying label size (MM or IN)
last_edited_attimestampnot nullTimestamp of the last edit
last_edited_by_user_iduuidnot null, foreign keyReference to the user who last edited the format
created_attimestampnot nullTimestamp of creation
created_by_user_iduuidnot null, foreign keyReference to the user who created the format
xmltextXML representation of the label format
xml_identifiertextIdentifier for the XML format

​
Usage and Functionality

The label_formats table is designed to be a comprehensive storage solution for label specifications. Here are some key points about its usage:
  1. Component-Specific Formats: Each label format is associated with a specific component, allowing for customized labeling solutions across different parts or products.
  2. Dimensional Flexibility: The table stores both the width and height of labels in millimeters, with an additional field for displaying sizes in either millimeters or inches, accommodating different measurement preferences.
  3. XML Support: The inclusion of XML fields allows for storing complex label designs that can be interpreted by label printing software or frontend rendering engines.
  4. Audit Trail: By tracking creation and last edit information, the table maintains a clear audit trail of changes to label formats.
  5. Security: Row-level security policies are implemented to ensure that users can only access and modify label formats associated with their company.

​
Notes

  • The table has foreign key relationships with the companies, components, and users tables, ensuring data integrity and proper associations across the database.
  • Row-level security is enabled on this table, which is crucial for maintaining data isolation between different companies using the system.
  • In the frontend application, this table is used in conjunction with the label_elements table to provide a complete label management system. Here’s an example of how label formats might be retrieved in the frontend: 
    const getLabels = async (
  componentId: string
): Promise<LabelFormatWithContents[]> => {
  const supabase = getSupabase();
  const { data: labelFormats, error: labelFormatsError } = await supabase
    .from("label_formats")
    .select("*")
    .eq("component_id", componentId)
    .returns<LabelFormat[]>();

  // ... additional logic to fetch and associate label elements
};
  • The XML fields (xml and xml_identifier) provide flexibility for storing and identifying complex label designs, potentially supporting integration with various label printing systems.
By leveraging the label_formats table, the Serial application can offer robust label management capabilities, allowing users to create, store, and manage label designs specific to their components while maintaining proper data segregation and security.