Datasources are an abstraction layer to handle different types of data storages in a type-independent way. Query by generalized rules, versioning, futurechanges, fallback, multiple servers are some feature examples. See Section 13, “Datasource” to learn about implementation of datasources.
Datasources are configured in two steps:
Datasource handles
define the
connections to specific data repositories (e.g. ldap, sql
databases, ...)
Datasources
use one or multiple
handles and define the abstract storage mechanism that
portlets can use.
For details on the configuration see Section 8.6, “datasource-section”
A simple database scheme, used for storing content published by Gentics Content.Node and all standard modules provided by Gentics. The ContentRepository may be versioning. You don’t need to access the repository by hand. Use Datasource for reading, the AdministrationPortlet for managing the data structure and Views for visualisation and data management.
Simplified ER diagram of a contentrepository:
A detailed SQL table layout can be found below.
Stores definitions of object types
Table 3.3. Columns of table contentobject
Column | Description |
---|---|
type | Unique type of this object. Gentics range is from 0 to 59999. Customertypes should have ranges of 1000 beginning from 100000. Integer, unique. |
name | Name of the object, preferable an i18n key, otherwise readable and displayed as-is. String, unique. |
id_counter | counter for object-ids (for generating unique
object ids), managed by the Datasource of type
contentrepository
|
exclude_versioning | Flag to mark objecttypes that are excluded from versioning. |
Stores definitions of attributes for object types
Table 3.4. Columns of table
contentattributetype
Column | Description |
---|---|
name | Internal name of an attribute. String, unique per object. |
attributetype | Type of this attribute. All attributes with same name must have same type, independent of their objecttype. See “Attribute Types” (Table 4.169) for a description of the possible attribute types. |
optimized | If this column is optimized for faster read access in the contentmap table. 1 or 0 |
quickname | The name of the column in the contentmap table, where this column is stored. Prefixed with "quick_". Column must be added and indexed manually if managed manually. Gentics Content.Node; Content.Repositories do this automaticaly. 1 or 0 |
multivalue | If this attribute is multivalue. Multivalue attributes must not be optimized. Multivalue attributes are represented by multi contentattribute rows with an optional sortorder. 1 or 0 |
objecttype | Which object this attribute belongs to. Integer, Relation to contentobject.type |
linkedobjecttype | Which object this attribute links to (attributetype 2 & 7). Integer |
foreignlinkattribute | In which attribute of the foreign object, the link to the current object is stored in (attributetype 7). Name of attribute. Text |
foreignlinkattributerule | Optional rule to restrict the objects related with this attribute (attributetype 7). You may use the object.attribute syntax to refer to the foreign object, but currently there is no way to access your source object. Text |
exclude_versioning | Flag to mark attributetypes that are excluded from versioning. |
Stores objects (one object per row)
Table 3.5. Columns of table contentmap
Column | Description |
---|---|
id | Unique row id (required for versioning) |
contentid | Contentid of the object (unique) |
obj_id | Id of the object (unique per obj_type) |
obj_type | Type of the object (refers to types in table contentobject) |
motherid | contentid of the mother object |
mother_obj_id | object id of the mother object |
mother_obj_type | Type of the mother object |
updatetimestamp | Timestamp of the last change in this row |
quick_... | optional quick columns (for every optimized attribute, see Section 4.3.2.2, “contentattributetype” |
Stores attributes of objects (each row for a value of an attribute).
Table 3.6. Columns of table contentattribute
Column | Description |
---|---|
id | unique row id (required for versioning) |
contentid | contentid of the object this attribute belongs to |
name | Name of the attribute, refers to the name in table contentattributetype |
value_text | Column for storing attribute values (types 1, 2 see Section 4.3.2.2, “contentattributetype” ) |
value_clob | Column for storing attribute values (type 5 see Section 4.3.2.2, “contentattributetype” ) |
value_blob | Column for storing attribute values (type 6 see Section 4.3.2.2, “contentattributetype” ) |
value_int | Column for storing attribute values (type 3 see Section 4.3.2.2, “contentattributetype” ) |
value_long | Column for storing attribute values (type 8 see Section 4.3.2.2, “contentattributetype” ) |
value_double | Column for storing attribute values (type 9 see Section 4.3.2.2, “contentattributetype” ) |
value_date | Column for storing attribute values (type 10 see Section 4.3.2.2, “contentattributetype” ) |
Sortorder | Sortorder for multivalue attributes |
Versioning table for contentmap (required when datasource is versioning).
Table 3.7. Columns of table
contentmap_nodeversion
Column | Description |
---|---|
... columns of contentmap | All columns of contentmap |
nodeversiontimestamp | Timestamp of the versioned record |
nodeversion_user | User reference (who created the version) |
nodeversionlatest | Flag for latest (current) versions of records |
nodeversionremoved | Timestamp of the removal of the record |
nodeversion_autoupdate | Flag for future record versions that still have to ba updated automatically (when nodeversiontimestamp is reached) |
Versioning table for contentattribute (required when datasource is versioning).
Table 3.8. Columns of table
contentattribute_nodeversion
Column | Description |
---|---|
... columns of contentmap | All columns of contentattribute |
nodeversiontimestamp | Timestamp of the versioned record |
nodeversion_user | User reference (who created the version) |
nodeversionlatest | Flag for latest (current) versions of records |
nodeversionremoved | Timestamp of the removal of the record |
nodeversion_autoupdate | Flag for future record versions that still have to be updated automatically (when nodeversiontimestamp is reached) |
This table may contain meta information about the contentrepository. Currently it is used to store the timestamp (lastupdate) when Gentics Content.Node; last synced content into the contentrepository. This is needed for datasource caching.
To reduce the number of SQL Statements needed to filter objects from a content repository and access attributes of the objects, the Gentics .Node PortalConnector provides a feature called "Attribute Prefetching".
To successfully use attribute prefetching, the attributes which will be used lateron an shall be prefetched have to be provided.
When using the Gentics .Node PortalConnector in Java Code:
// this is the datasource we are using Datasource ds = ...; // generate an expression to filter all pages (objects of type "10007") // from the content repository Expression expr = ExpressionParser.getInstance().parse("object.obj_type == 10007"); // now create a (reusable) datasource filter for our datasource DatasourceFilter filter = ds.createDatasourceFilter(expr); // now comes the magic, get the objects and have the names prefetched Collection objects = ds.getResult(filter, new String[] {"name"});
When using the DatasourceQueryImp in a template:
// set the filter rule to get all pages (objects of type "10007") #set($portal.imps.query.rule = "object.obj_type == 10007") // now comes the magic, have the names prefetched #set($portal.imps.query.prefillAttributes = ["name"]) // now get the objects #set($pages = $portal.imps.query.result)
<datasourcetreecomponent> ... // set the root rule to get all pages (objects of type "10007") <rootrule>object.obj_type == 10007</rootrule> // now comes the magic, have the names prefilled <prefillattributes>name</prefillattributes> </datasourcetreecomponent>
How does the attribute prefetching actually work? What about the caches? The steps to filter objects and prefetch attributes are
[number of objects] x [number of
attributes]
prefetchAttribute.threshold
(which defaults to
1000
). If that is the case, prefetch all
attributes with a single (or at least few)
SQL statements (algorithm finishes here).
prefetchAttribute.threshold
, start fetching the attributes from the
cache.
Calculate a threshold for cache misses
(attributes not found in the cache) by
taking the lesser of
prefetchAttribute.cacheMissThreshold
(defaults to
100
) and the percentage given in
prefetchAttribute.cacheMissThresholdPerc
(defaults to
20
) of the total number of attributes to
prefetch.
Example: 20 objects are filtered, and 2 attributes prefetched per object.
Table 3.10.
Total number of attributes: | 20 x 2 = 40 |
absolute cachemiss threshold | configured to 100 |
relative cachemiss threshold (20%) | 40 x 20 / 100 = 8 |
effective cachemiss threshold | min(100, 8) = 8 |