 |
The Hibernate mapping files are the authoritative reference. These are the *.hbm.xml files which have been bundled into the main Confluence .jar file in recent releases. |
This document is little more than the Confluence schema with added comments, but the priority was placed on making the information available.
General Database Diagram

Authentication
Atlassian-user
This is the "new" authentication system, which is more flexible and extensible than OpenSymphony.
local_members: establishes many-to-many association between users and groups.
external_entities: Maps users and groups from LDAP (or any other external authentication system) to IDs in Confluence DB
external_members: associates LDAP (or other external) users with local groups.
OpenSymphony
The "old" authentication system, which was the default prior to 2.7.
Content
The actual information that users are storing and sharing.
attachmentdata: stores the binary data for attached files.
Only used when Confluence is configured to store attachments in the database; otherwise, attachments are stored in the local filesystem.
attachments: metadata for attachments.
bodycontent: stores the actual content of Confluence pages. No versioning information or other metadata is stored here, though; that's all in the content table.
content: a persistence table for the ContentEntityObject class of objects. The subclass is indicated by the contenttype column.
content_label: Arbitrary text labels for content.
label: the other half of the content_label system.
content_perm: content-level permissions objects.
content_perm_set: one-to-many mapping for content items and their permissions, with added metadata.
Clustering
clustersafety: normally, this table only contains one row. The value of the safetynumber is what Confluence uses to find out whether another instance is sharing its database without being part of the cluster.
System information
confversion used by the upgrade system to determine what to expect from the database, so as to negotiate upgrades.
plugindata: records which plugins have been installed, and when.
data is a blob of the actual plugin .jar file. This is principally cluster-related.
Spaces
spacegroups: this table is only used by the hosted environment.
spaces: information about the spaces themselves: key, human-friendly name and numeric ID.
Appearance
decorator: storage of custom display templates, for customising layouts.
Miscellaneous
os_propertyentry: for arbitrary association of entities and properties.
bandana: a catch-all persistence layer. It contains things like user settings and space- and global-level configuration data, and is used as storage by plugins such as the Dynamic Task List plugin. Essentially, for storing arbitrary data that doesn't fit anywhere else.
extrnlnks: storage of referral links.
hibernate_unique_key: used by the high/low ID generator - the subsystem which generates our primary keys.
Mess with this at the cost of being able to create objects.
indexqueueentries: arbitrates full-content indexing across the system.
This table generally contains the last 12 hours or so of updates, to allow re-syncing of cluster nodes after restarts.
keystore: used by the trusted apps framework to store the server's private key, and other servers' public keys.
links: tracks links within the server (i.e. across and within spaces).
notifications: storage of page- and space-level watches.
pagetemplates: acts as the back-end of the templates feature.
confancestors: used to speed up permissions checks, by allowing quick lookup of all a page's ancestors.
Comments (3)
Mar 21, 2008
Royce Wong says:
I am using Confluence 2.7.1. Having problems after switching to LDAP. For users ...I am using Confluence 2.7.1. Having problems after switching to LDAP. For users that are both "local" and exist in LDAP, all their original group assignment disappeared. The transition definitely need some work. It should check if local user exists in LDAP, if so add the user to EXTERNAL_ENTITIES table and migrate the user's groups. I am sure Atlassian is also aware that for users that are both local and in LDAP, they are showing up twice in user browser.
Also, how is the value for EXTERNAL_ENTITIES.TYPE column being determined?
These are my test results for the value for EXTERNAL_ENTITIES.TYPE column on first time user login after LDAP integration:
Shouldn't the values for "LDAP only user" be the same?
I also tested user login via SOAP API, although the "first time" login was successful, NO record was created for the user in EXTERNAL_ENTITIES table.
Thanks. I created a ticket for this http://jira.atlassian.com/browse/CONF-11181
The ability to translate local membership into external membership for initial LDAP integration
http://jira.atlassian.com/browse/CONF-10654
Migration to LDAP authentication - maintaining existing group information
http://forums.atlassian.com/thread.jspa?messageID=257277022�
User browser shows duplicate accounts when a user exists both locally and in LDAP
http://jira.atlassian.com/browse/CONF-8098
Atlassian-user should support password authentication only to LDAP (like OSUser)
http://jira.atlassian.com/browse/CONF-11115
Jul 07
Anonymous says:
we can't add comments in our confluencewe can't add comments in our confluence
Jul 08
Azwandi Mohd Aris says:
Hi there, Would you be able to raise a support request at http://support.atlass...Hi there,
Would you be able to raise a support request at http://support.atlassian.com to further describe the problem?
Cheers,
Azwandi
Add Comment