Each row in the content table is considered an object. All objects are composites meaning that different plugins handle different fields of the object. We do not have a function that load the whole object. Although it could be practical in some cases, we instead let each plugin handles their own data as required. For example, if the robots.txt plugin needs to know whether a page is indexable then it reads the corresponding link. In most other cases, however, that link is ignored because it is not important; i.e. boxes on the side also have that link, but robots.txt does not use it because boxes are an artifact in the main page being presented.

Similarly, users are uniquely identified by their email in the users table.

So the full object identity is represented as "<table name>.<row key>". In pretty much all cases the table name can be inferred. At least at this time all references to an object are defined as <row key> and we know because of the name of that reference (the cell key) what the table is being referenced. For example the Files table is referenced from the Content table in cells named content::attachment::<branch>.<revision> which have the original file md5.

The objects themselves are composed of cells in the Cassandra database. The naming convention used for the cells is

<plugin name>::<field name>

Because certain cells get used between multiple plugins, multiple plugin names may appear in the cell name. For example a link has to include the name of two plugins:

links::<plugin name>::<field name>[-<server name>-<unique id>]

Similarly, the form plugin can automatically save fields and those get named with the form field name which includes the plugin name and the name of the HTML input field. This combination means the final name in the database includes multiple plugin names.

See: Signals & Functions feature (triggers, actions, rules)

See: Batch Work feature [core]