Storing Data in the Content Repository

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.

Define an Item Type

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:

• Title
• Description
• Publication or Posting Date
• Author or Contributor
• MIME Type
• Binary or Text Data

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:

  create table images (
    image_id       integer
                   constraint images_image_id_fk
                   references cr_revisions
                   constraint images_pk
                   primary key,
    width          integer,
    height         integer
  );

Content types are nothing more than standard ACS Objects that inherit from content_revision:

begin

 acs_object_type.create_type (
   supertype => 'content_revision',
   object_type => 'image',
   pretty_name => 'Image',
   pretty_plural => 'Images',
   table_name => 'images',
   id_column => 'image_id',
   name_method => 'acs_object.default_name'
 );

 acs_attribute.create_attribute (
   object_type => 'image',
   attribute_name => 'width',
   datatype => 'number',
   pretty_name => 'Width',
   pretty_plural => 'Widths'
 );

 acs_attribute.create_attribute (
   object_type => 'image',
   attribute_name => 'height',
   datatype => 'number',
   pretty_name => 'Height',
   pretty_plural => 'Heights'
 );

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 organizing data in a hierarchical fashion in a manner similar to a filesystem. 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, we can simply define a relationship between user and image as ACS Objects:

  acs_rel_type.create_role('user');
  acs_rel_type.create_role('portrait');

  acs_rel_type.create_type( rel_type => 'user_portrait_rel',
     pretty_name => 'User Portrait',
     pretty_plural => 'User Portraits',
     object_type_one => 'user',
     role_one => 'user',
     min_n_rels_one => 1,
     max_n_rels_one => 1,
     object_type_two => 'content_item',
     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, we can start storing portraits. The DML for processing a new 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
    # be used directly with blob_dml_file
    :revision_id := content_revision.new(:title, :description, $publish_date,                               :mime_type, NULL, :text, 'content_revision', 
                               :item_id, :revision_id);
    blob_dml_file update cr_revisions set content = empty_blob() ...
    :rel_id := acs_rel.new(...)

Retrieve Objects

  ns_ora write_blob ...

Last Modified: $Id: storage.html,v 1.4 2024/09/11 06:15:47 gustafn Exp $