Bug 103242 - normalize storage of serialized OIDs
Summary: normalize storage of serialized OIDs
Alias: None
Product: Red Hat Web Application Framework
Classification: Retired
Component: other   
(Show other bugs)
Version: nightly
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: ccm-bugs-list
QA Contact: Jon Orris
Depends On:
TreeView+ depends on / blocked
Reported: 2003-08-28 00:33 UTC by Vadim Nasardinov
Modified: 2007-04-18 16:57 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-08-03 18:28:42 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Vadim Nasardinov 2003-08-28 00:33:12 UTC
We're starting to store serialized OIDs as a way to build generic
services.  There are currently two examples that I am aware of.

1. The versioning service uses serialized OIDs for tracking data

    create table vcx_obj_changes (
        id INTEGER not null
            constraint vcx_obj_changes_id_p_hvgb7
              primary key,
        txn_id INTEGER,
        obj_id VARCHAR(400) not null

   The OBJ_ID column stores serialized OIDs.

2. The latest and greatest publishing proposal by Archit, Mike, and
   Scott uses OIDs to track links between data objects.  See


(As a parenthetical aside, I'd like to point out that this is a
reincarnation of the on_what_table/on_which_id modeling technique used
in ACS Tcl.  See

This means we are increasing the number of instances where the name of
an object type is stored in the database.  This raises two concerns
that may need to be addressed -- the sooner, the better.

 * Versioning currently has its own private implementation for OID
   serialization/deserialization.  This should probably be made public
   and moved someplace else.

 * It would be really nice if we 3NF-ed the OID storage format.  In other words,
   instead of having a bunch of values like


   stored in the database, we could have a canonical listing of all
   known object types stored in a single table, like so:

    1 | com.arsdigita.foo.Bar
    2 | com.arsdigita.foo.Grob
    3 | com.arsdigita.cms.NewsItem
    4 | com.arsdigita.cms.MultiPageArticle

Instead of storing com.arsdigita.foo.Bar:2343 and
com.arsdigita.cms.NewItem:3093 would could store 1:2343 and 3:3093.
This would allow us to easily rename the object type, should we decide
to go from com.arsdigita.cms.NewsItem to com.redhat.cms.NewsItem.
Would also save storage.

Comment 1 Richard Li 2003-08-28 14:11:57 UTC
Scott says:

I'm not sure if this is relevant to Vadim's overall goal here, but in reality,
we're unlikely to implement direct OID references for the Rickshaw publishing

Archit's proposed model for PublishedLink was:

object type PublishedLink {
   composite ContentItem[1..1]    pending;
   String[1..1]         sourceOID;
   String[1..1]         attribute;
   composite ContentItem[1..1]    target;
   object key(pending, sourceOID, attribute, target);

In this model there are three object links. pending and target are direct
ContentItem associations, as required by the model. The direct parent (i.e. the
particular Item component which contains the association) is modeled as an OID.
As a simplification in order to minimize additional work for the Rickshaw
timeframe, I had proposed restricting the direct parent to being an ACSObject,
resulting in the following PublishedLink definition:

 object type PublishedLink {
    composite ContentItem[1..1]    pending;
    ACSObject[1..1]         pendingSource;
    String[1..1]         attribute;
    composite ContentItem[1..1]    draftTarget;
    object key(pending, pendingSource, attribute, draftTarget);

This restriction would mean that for a component of a ContentItem to contain a
direct reference to another top-level ContentItem, it would have to be a subtype
of ACSObject. This won't be a problem in terms of existing site upgrades, as the
 current publishing system requires such components to extend ContentItem, so
this is still a relaxation, abeit a somewhat more modest one than originally

Ultimately, we probably do want to support arbitrary DomainObject instances, but
given the tight Rickshaw timeframe and the lack of clear use cases which require
non-ACSObject components of ContentItems to reference top-level ContentItems, it
seems to be a reasonable restriction to make, as it simplifies the required

Comment 3 Daniel Berrange 2003-08-28 15:02:25 UTC
On a related note, it strikes me that we should also add a persistence base type
for OID, so instead of

object type PublishedLink {
   composite ContentItem[1..1]    pending;
   String[1..1]         sourceOID;
   String[1..1]         attribute;
   composite ContentItem[1..1]    target;
   object key(pending, sourceOID, attribute, target);

We could define:

object type PublishedLink {
   composite ContentItem[1..1]    pending;
   OID[1..1]         sourceOID;
   String[1..1]         attribute;
   composite ContentItem[1..1]    target;
   object key(pending, sourceOID, attribute, target);

cf fz 102297


Comment 4 Vadim Nasardinov 2003-08-28 15:09:57 UTC
I think we need to add a "me too" button to the Bugzilla interface so
I don't have to type, "I fully support Dan's proposal".

Comment 5 Vadim Nasardinov 2005-08-03 18:28:42 UTC

Note You need to log in before you can comment on or make changes to this bug.