Red Hat Bugzilla – Bug 103242
normalize storage of serialized OIDs
Last modified: 2007-04-18 12:57:11 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.
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.
The URL for Scott's comment is http://post-office.corp.redhat.com/archives/ccm-engineering-list/2003-August/msg00105.html Message-ID is <3F4D896F.60901@redhat.com> See also David's post to the same thread: http://post-office.corp.redhat.com/archives/ccm-engineering-list/2003-August/msg00106.html Message-Id: <1062052812.1489.137.camel@lemon.watzmann.net>
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
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".
stale