Skip to content

Limetypes and Limeobjects

At its core, the web-client is a database software. Its aim is to connect, store and analyse individual as well as collections of limeobjects, not dissimilar from what a database management system (DBMS) achieves. The writing, reading, and aggregation of limeobjects are all performed in the database layer. It is therefore useful to have a deeper understanding of what the database is doing and how its data model translates to our brand nomenclature for limeobjects and limetypes.

What are Limetypes and Limeobjects

Limeobjects are instances of limetypes. They are abstract objects that encapsulate some data. Limetypes, in turn, tell us what kind of limetype properties we expect our limeobject to have. This is analoguous to object instances and interfaces in languages like Java or TypeScript. Some limetypes come shipped with our base solution, but you can—and typically will—define custom limetypes in LISA as well.

For example, for a given solution, Deal could be a limetype1, and a given Deal would then be a limeobject. A deal limeobject—because of its limetype Deal—is expected to have say a name, a related coworker (responsible for the deal), a bunch of todos, and so on and so forth.

System Properties

All limetypes themselves inherit, at least implicitly, from some common interface—we expect all limetypes to have what we call system properties. System properties are special properties we expect to exist on any limeobject regardless of its limetype. In our APIs, we also prefix system properties with an underscore. The system properties include2:

  • _id: the id of the limeobject
  • _createdtime: the timestamp of the creation time for this limeobject 3
  • _createduser: the user who created the limeobject
  • _descriptive: a descriptive that defaults to the name of the limeobject when created
  • _sys_group: the id of the group

  • _sys_permissions: a decimal representation of the corresponding permission in octal notation, similar to file system permissions in UNIX-based systems. Each triad tells us

    • What the owner can do
    • What the group can do
    • What other users can do

  • _sys_owner: the id of the user who owns the limeobject

  • _timestamp: the timestamp of the latest update to the limeobject
  • _updateduser: the user who last updated the limeobject

Properties in Detail

In brief, limeobjects are rows in database tables. The corresponding table is the table for the limetype to which the limeobject belongs. That is, there exists a Company table, a History table, and so on and so forth. When new limetypes are defined in LISA, among other things, it adds more tables to the database.

Every limetype—being like a table—has a set of associated properties you might think of as columns. These properties can be divided into different types.

Basic Properties

These are properties that are neither system or related properties. They do not reference other limetypes, and they are specific to the limetype they belong to. Examples include name`` andaddress`.

System Properties

These were defined earlier. These are properties you would expect to see on all limeobjects regardless of limetype. Examples include `_createdtime``.

Finally, there are related properties. These are properties referring to another limetype which bears some kind of relation to the limeobject. Such a relation is, concretely speaking, just a relation in the sense of databases. These properties can either come directly from a cell in the limeobject row, in which case they are foreign keys to the other limetype, or come from a cell on the related limetype table, in which case there is a foreign key to your limeobject from that table.

For instance, a company in the base solution can have 0 or 1 coworkers. Therefore there is a foreign key called “coworker” on the Company table that points to the coworker for the company in the Coworker table. The diagram below illustrates this:

Similarly, a company can have many people, which means there is a foreign key, “company”, on the Person table pointing to the company for the person in the Company table. This situation might look something like

Note that the default limetypes are always one-to-many or many-to-one, where the “many” side is the one with the foreign key.

Lime often uses her own nomenclature when it comes to these entities. The following terms are useful to remember

  1. Limeobject - an object encapsulating information coming from a row in a limetype table.
  2. Limetype - an interface with which we define the schema for a limetype table, as well as limeobjects of that type.
  3. Hasmany property - a related limetype on a limeobject for which a one-to-many relation exists to the related limetype table—that is, the limeobject can be associated with many objects of the related limetype.
  4. Belongsto property - a related limetype on a limeobject for which a many-to-one relation exists to the related limetype table—that is, the lime object can be associated with only 0 or 1 objects of the related limetype.
  5. Hasone property - a related limetype on a limeobject for which at most one related object exists4
  6. Hasandbelongstomany property - a related limetype on a limeobject for which a many-to-many relation exists to the related limetype table5

Where can I see these properties and learn more?

There are a million ways to see the available properties. To do it fast, you could run limefu limetypes list as well as limefu limetypes info [limetype name]. The API documentation also covers the limeobject endpoint, which returns all available properties on limeobjects.

Finally, you could—and should—get out your database browser and open up the hood of your database. This way you'll really understand the data model.

  1. While most of our solutions have the limetype Deal, many of our solutions are configured to use the name "Business" instead. ↩

  2. For what it's worth, there are some obscure system properties not mentioned, most of the remaining ones are SQL macros injected into file table queries to get e.g., the file size. ↩

  3. Interestingly, the createdtime and timestamp are not typically equal even when the object has just been created. In such a case they would vary by a few milliseconds due to limitations in code execution speed, with the timestamp coming in shortly after the createdtime. ↩

  4. You may think that, at the database level, there's nothing distinguishing a hasone from a belongsto property, and it seems you would be right. There also does not seem to be much of a semantic difference, although based on an object DSL I found Document objects are considered hasone for whatever reason. So far I have only seen both concepts used interchangably. That means if you write code referencing the belongsto concept, you'll likely want to include the hasone concept as well. ↩

  5. You would use an association table to implement many-to-many relations. Likewise, one-to-one relations exist by requiring the constraint on the foreign key to be unique, although this constraint is not present in our base solution limetype tables. ↩