Container Object
The container object allows storing more than one data element per attribute in an object. To use the container set the datatype in acs_attributes to the object_type to be stored. The value stored in the attribute is a container object. This provides a pointer to the contained objects and provides a generic mechanism for creating a hierarchy of objects.
Implementation
The container object_type keeps the information about where the container is contained. The subclasses keep track of what is contained. The first implementation will be a list container that allows storing lists of objects, numbers, strings and dates in an attribute. The length of the list is controlled by min_n_values and max_n_values in acs_attributes. The table structure consists of
table container (
container_id references acs_objects(object_id)
parent_id references acs_objects(object_id)
attribute_id references acs_attributes(attribute_id)
)
table container_list (
container_list_id references container(container_id)
)
table container_list_map (
container_list_id references container_list(container_list_id)
sort_order default container_list_map_seq.next_val
object_id references acs_objects(object_id)
number number
date date
string varchar(100)
primary key container_list_id, sort_order
)
Notes: The container will support updating the sort order and still function correctly (sort order must be a positive number because deleted items will have a negative sort_order). This deleted 'flag' allows the container to run in garbage collect mode. This allows quick deletion of large number of objects with a scheduled task to clean up the mess. The object_id, number, string and date columns store the typed data. If data larger than varchar(100) needs to be stored it's best to create an object_type like big_string. This keeps the containter_list_map column width reasonable.
Also adding a key column in a similar table would create an TCL array type container.
Methods
SQL
container_list.new() create a new container list object
container_list.get_attribute(object_id,attribute_name) will return a TCL list of values
container_list.del_item(object__id,attribute_name,sort_order) will delete the value stored at sort order
container_list.lappend(object_id,attribute_name,value)
other TCL list functions such as linsert may follow
TCL
container::container_p object_id returns true if object is a container
container_list::get object_id attribute_name returns the result of container_list.get_attribute
The following will be implemented in a later release.
container::get_schema object_type returns an xml schema for the object_type
container:;get_xml object_id returns an XML document for the object
container::insert_xml object_type xml returns object_id and inserts XML into that object
These functions will allow exporting data from one ACS install and importing it into another without object_id problems.
Core Changes
None required, but I might be nice to make a storage_types table and make a foreign key to acs_attributes.storage. That combined with modifying get and set attribute would allow storing typed data in a generic way. It would also allow other types of storage such as XML and CMS. Future improvements could be get_xpath_attribute and set_xpath_attribute.
Comments?
