This document provides an introduction to using the content +
This document provides an introduction to using the content repository for storing data (binary or text files) and associated attributes. It describes how to store user portraits as an -example.
The first step towards using the content repository is to define +example.
+The first step towards using the content repository is to define one or more content types for the data you wish to -manage.
The basic content item includes the following attributes:
The basic content item includes the following attributes:
+Most types of content require additional attributes. For a +
Most types of content require additional attributes. For a photo, we probably also want to store the pixel width and height at -the very least:
+the very least: ++create table images ( image_id integer constraint images_image_id_fk @@ -23,8 +28,10 @@ width integer, height integer ); -Content types are nothing more than standard ACS Objects that -inherit from content_revision:
++Content types are nothing more than standard ACS Objects that +inherit from content_revision:
+begin acs_object_type.create_type ( @@ -56,17 +63,23 @@ end; / show errors -Note that content types always extend content_revision, -rather than content_item. This is because we want to store -multiple revisions of both the actual data (in this case the image) -as well as associated attributes (the width and height of the image -may vary among revisions).
Define a Relationship to a Target Object
The content repository implements a flexible mechanism for +
Note that content types always extend +content_revision, rather than content_item. +This is because we want to store multiple revisions of both the +actual data (in this case the image) as well as associated +attributes (the width and height of the image may vary among +revisions).
+The content repository implements a flexible mechanism for organizing data in a hierarchical fashion in a manner similar to a file system. This would be useful if we ever decided to allow each user to manage an entire personal photo gallery rather than a -single portrait.
In the simple case where each user is allowed a single portrait, +single portrait.
+In the simple case where each user is allowed a single portrait, we can simply define a relationship between user and image as ACS -Objects:
+Objects: ++acs_rel_type.create_role('user'); acs_rel_type.create_role('portrait'); @@ -81,13 +94,17 @@ min_n_rels_two => 0, max_n_rels_two => 1 ); -Note that the user object is related to a -content_item object rather than an image object -directly. Each image object represents only a single -revision of a portrait. Revisions always exist in the context of an -item.
Store Objects
Now we have defined both a content type and relationship type, +
Note that the user object is related to a +content_item object rather than an image +object directly. Each image object represents only a +single revision of a portrait. Revisions always exist in the +context of an item.
+Now we have defined both a content type and relationship type, we can start storing portraits. The DML for processing a new -portrait upload form would look like this:
+portrait upload form would look like this: ++begin transaction :item_id := content_item.new(:name, :item_id, sysdate, NULL, '[ns_conn peeraddr]'); # maybe have content_revision return the LOB locator so that it can @@ -96,8 +113,12 @@ :item_id, :revision_id); blob_dml_file update cr_revisions set content = empty_blob() ... :rel_id := acs_rel.new(...) -Retrieve Objects
++Retrieve Objects
+ns_ora write_blob ... -
karlg@arsdigita.comLast Modified: $Id: storage.html,v 1.1.1.1 2001/03/13 22:59:26 -ben Exp $
- +
Last Modified: $Id: storage.html,v 1.1.1.1.30.1 2016/06/22 +07:40:41 gustafn Exp $