Bug 103242
Summary: | normalize storage of serialized OIDs | ||
---|---|---|---|
Product: | [Retired] Red Hat Web Application Framework | Reporter: | Vadim Nasardinov <vnasardinov> |
Component: | other | Assignee: | ccm-bugs-list |
Status: | CLOSED WONTFIX | QA Contact: | Jon Orris <jorris> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | nightly | CC: | archit.shah, mikeb, sseago |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-08-03 18:28:42 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Vadim Nasardinov
2003-08-28 00:33:12 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 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> 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.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 |