AEM Data Modeling

Seven Simple Rules that how AEM Data model works

Rule #1: Data First, Structure Later. Maybe.

Not to worry about a declared data structure in an ERD sense. Initially. Structure is expensive and in many cases it is entirely unnecessary to explicitly declare structure to the underlying storage.

Example

The above example of using a lastModified Date property on for example "blog post" node, really does not mean that there is a need for a special nodetype. I would definitely use nt:unstructured for my blog post nodes at least initially. Since in my blogging application all I am going to do is to display the lastModified date anyway (possibly "order by" it) I barely care if it is a Date at all. Since I implicitly trust my blog-writing application to put a "date" there anyway, there really is no need to declare the presence of a lastModifieddate in the form a of nodetype.

Rule #2: Drive the content hierarchy, don't let it happen.

he content hierarchy is a very valuable asset. So don't just let it happen, design it. If you don't have a "good", human-readable name for a node, that's probably that you should reconsider. Arbitrary numbers are hardly ever a "good name".

Example

I would model a simple blogging system as follows. Please note that initially I don't even care about the respective nodetypes that I use at this point.

Example

I would model a simple blogging system as follows. Please note that initially I don't even care about the respective nodetypes that I use at this point.

1 2 3 4 5 6 7

/content/myblog /content/myblog/posts /content/myblog/posts/what_i_learned_today /content/myblog/posts/iphone_shipping   /content/myblog/comments/iphone_shipping/i_like_it_too /content/myblog/comments/iphone_shipping/i_like_it_too/i_hate_it

Using the above content model I can easily allow the "anonymous" user to "create" comments, but keep the anonymous user on a read-only basis for the rest of the workspace.

Rule #3: Workspaces are for clone(), merge() and update().

Workspaces are the boundary for references and query.

If you don't use clone(), merge() or update() methods in your application a single workspace is probably the way to go.

If you have a considerable overlap of "corresponding" nodes (essentially the nodes with the same UUID) in multiple workspaces you probably put workspaces to good use.

Workspaces should not be used for access control. Visibility of content for a particular group of users is not a good argument to separate things into different workspaces. JCR features "Access Control" in the content repository to provide for that.

Example

Use workspaces for things like:

• v1.2 of your project vs. a v1.3 of your project
• a "development", "QA" and a "published" state of content

Do not use workspaces for things like:

• user home directories
• distinct content for different target audiences like public, private, local, ...
• mail-inboxes for different users

Rule #4: Beware of Same Name Siblings.

While Same Name Siblings (SNS) have been introduced into the spec to allow compatibility with data structures that are designed for and expressed through XML and therefore are extremely valuable to JCR, SNS come with a substantial overhead and complexity for the repository.

Any path into the content repository that contains an SNS in one of its path segments becomes much less stable, if an SNS is removed or reordered, it has an impact on the paths of all the other SNS and their children.

For import of XML or interaction with existing XML SNS maybe necessary and useful but I have never used SNS, and never will in my "green field" data models.

Example

Use

1 2	/content/myblog/posts/what_i_learned_today /content/myblog/posts/iphone_shipping

Code samples are intended for illustration purposes only.

instead of

1 2	/content/blog[1]/post[1] /content/blog[1]/post[2]

Code samples are intended for illustration purposes only.

Rule #5: References considered harmful.

References imply referential integrity. I find it important to understand that references do not just add additional cost for the repository managing the referential integrity, but they also are costly from a content flexibility perspective.

Personally I make sure I only ever use references when I really cannot deal with a dangling reference and otherwise use a path, a name or a string UUID to refer to another node.

Example

Let's assume I allow "references" from a document (a) to another document (b). If I model this relation using reference properties this means that the two documents are linked on a repository level. I cannot export/import document (a) individually, since the reference property's target may not exist. Other operations like merge, update, restore or clone are affected as well.

So I would either model those references as "weak-references" (in JCR v1.0 this essentially boils down to string properties that contain the uuid of the target node) or simply use a path. Sometimes the path is more meaningful to begin with.

I think there are use cases where a system really can't work if a reference is dangling, but I just can't come up with a good "real" yet simple example from my direct experience.

Rule #6: Files are Files.

Explanation

If a content model exposes something that even remotely smells like a file or a folder I try to use (or extend from) nt:file, nt:folder and nt:resource.

In my experience a lot of generic applications allow interaction with nt:folder and nt:files implicitly and know how to handle and display those event if they are enriched with additional meta-information.

For example a direct interaction with file server implementations like CIFS or WebDAV sitting on top of JCR become implicit.

I think as good rule of thumb one could use the following: If you need to store the filename and the mime-type then nt:file/nt:resource is a very good match. If you could have multiple "files" an nt:folder is a good place to store them.

If you need to add meta information for your resource, let's say an "author" or a "description" property, extendnt:resource not the nt:file. I rarely extend nt:file and frequently extend nt:resource.

Example

Let's assume that someone would like to upload an image to a blog entry at:

1	/content/myblog/posts/iphone_shipping

Code samples are intended for illustration purposes only.

and maybe the initial gut reaction would be to add a binary property containing the picture.

While there certainly are good use cases to use just a binary property (let's say the name is irrelevant and the mime-type is implicit) in this case I would recommend the following structure for my blog example.

1 2 3

/content/myblog/posts/iphone_shipping/attachments [nt:folder] /content/myblog/posts/iphone_shipping/attachments/front.jpg [nt:file] /content/myblog/posts/iphone_shipping/attachments/front.jpg/jcr:content [nt:resource]

Rule #7: IDs are evil.

Explanation

In relational databases IDs are a necessary means to express relations, so people tend to use them in content models as well. Mostly for the wrong reasons through.

If your content model is full of properties that end in "Id" you probably are not leveraging the hierarchy properly.

It is true that some nodes need a stable identification throughout their live cycle. Much fewer than you might think though. mix:referenceable provides such a mechanism built into the repository, so there really is no need to come up with an additional means of identifying a node in a stable fashion.

Keep also in mind that items can be identified by path, and as much as "symlinks" make way more sense for most users than hardlinks in a unix filesystem, a path makes a sense for most applications to refer to a target node.

More importantly, it is **mix**:referenceable which means that it can be applied to a node at the point in time when you actually need to reference it.

So let's say just because you would like to be able to potentially reference a node of type "Document" does not mean that your "Document" nodetype has to extend from mix:referenceable in a static fashion since it can be added to any instance of the "Document" dynamically.

Example

use:

1	/content/myblog/posts/iphone_shipping/attachments/front.jpg

Code samples are intended for illustration purposes only.

instead of:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

[Blog] -- blogId -- author [Post] -- postId -- blogId -- title -- text -- date [Attachment] -- attachmentId -- postId -- filename + resource (nt:resource)

Further updates can also be seen on http://wiki.apache.org/jackrabbit/DavidsModel.