Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
First Last Prev Next    This bug is not in your last search results.
Bug 103242 - normalize storage of serialized OIDs
normalize storage of serialized OIDs
Status: CLOSED WONTFIX
Product: Red Hat Web Application Framework
Classification: Retired
Component: other (Show other bugs)
nightly
All Linux
medium Severity medium
: ---
: ---
Assigned To: ccm-bugs-list
Jon Orris
:
Depends On:
Blocks:
  Show dependency tree / graph
 
Reported: 2003-08-27 20:33 EDT by Vadim Nasardinov
Modified: 2007-04-18 12:57 EDT (History)
3 users (show)

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

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

  None (edit)
Description Vadim Nasardinov 2003-08-27 20:33:12 EDT 
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
   objects:

    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

  
http://post-office.corp.redhat.com/archives/ccm-engineering-list/2003-August/msg00086.html
  
http://post-office.corp.redhat.com/archives/ccm-engineering-list/2003-August/msg00088.html

(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
http://www.google.com/search?q=on_which_table+on_what_id)

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

     com.arsdigita.foo.Bar:2343
     com.arsdigita.foo.Bar:938493
     com.arsdigita.foo.Grob:394820
     etc.

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

   ID | OBJECT_TYPE
   ---+----------------------
    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 10:11:57 EDT 
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
design.

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
proposed.

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
implementation.
Comment 3 Daniel Berrange 2003-08-28 11:02:25 EDT 
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

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=102297
Comment 4 Vadim Nasardinov 2003-08-28 11:09:57 EDT 
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 14:28:42 EDT 
stale
Note You need to log in before you can comment on or make changes to this bug.
First Last Prev Next    This bug is not in your last search results.