[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] [RS Issue] Need clarification on comment on line 1410
I like Duane's idea as well. However, I also think that in a such case we should also (automatically) deprecate all objects that reference the deprecated object. For example, it doesn't make sense to keep an Association with a "valid" status (approved) that references a deprecated object. It raises another question related to the RS specs. What is the reason that we don't deprecate objects that reference objects that were deprecated after their creation? Going back to the Matt's example it formally means that an Association A that associates an employee E with a department D is still valid without any information on the Association level that it references a deprecated object (an employee who left the company). Or we can end up with valid Associations that associate the same position with two different people when one of them already left the company. Both options deprecation and object replacement are valuable to me. I think that we can go ahead with what we already have but for the next release we could also consider the object replacement option as well because it may be useful in some cases. Regards, Goran ----- Original Message ----- From: "Farrukh Najmi" <Farrukh.Najmi@Sun.COM> To: <regrep@lists.oasis-open.org> Sent: Monday, January 24, 2005 12:13 PM Subject: Re: [regrep] [RS Issue] Need clarification on comment on line 1410 > Duane Nickull wrote: > >> >> >> Farrukh Najmi wrote: >> >>> >>> >>>> >>>> Automatic notification to the owners of the references? >>> >>> >>> >>> I think there should be no automatic notifications in the system because >>> notifications are expensive and should be tightly controlled. >> >> >> I guess in practice, if a registry object is *really* important to a >> user, they should subscrtibe to its' auditable events. That way, if they >> assert a reference or association, they do have a mechanism to be >> notified and do something. > > Precisely! And only the user knows which objects are of importance to > them. So let then subscribe explicitly using our event notification > feature. > >> >> Duane >> >> >>> >>>> >>>> Duane >>>> >>>> Goran Zugic wrote: >>>> >>>>> I think that we should not allow a RegistryObject to be deleted if it >>>>> has >>>>> references to it. Having RegistryObjects that reference other >>>>> RegistryObjects that do not exist change basic referential integrity >>>>> principal. >>>>> >>>>> Matt's idea about routine business evolution cases makes sense to me >>>>> and I >>>>> agree that a Registry Administrator only could remove a referenced >>>>> RegistryObject. The RegistryAdministrator should be allowed to do >>>>> this >>>>> operation only if an object replacement is provided so that the >>>>> referential >>>>> integrity principal is still in place. I hope that a reference to new >>>>> object >>>>> could be added as the RemoveObjectsRequest attribute. >>>>> >>>>> Regards, >>>>> Goran >>>>> >>>>> ----- Original Message ----- From: "Farrukh Najmi" >>>>> <Farrukh.Najmi@Sun.COM> >>>>> To: <regrep@lists.oasis-open.org> >>>>> Sent: Saturday, January 22, 2005 5:46 PM >>>>> Subject: Re: [regrep] [RS Issue] Need clarification on comment on line >>>>> 1410 >>>>> >>>>> >>>>>> Matthew MacKenzie wrote: >>>>>> >>>>>>> Sorry, that is unclear. >>>>>>> >>>>>>> Currently, if a removal is attempted against an object that has >>>>>>> live >>>>>>> references, the removal is aborted -- a very safe approach to be >>>>>>> sure. >>>>>>> My thought was that we could possibly make this more intelligent and >>>>>>> at >>>>>>> the same time allow the registry to deal with routine business >>>>>>> evolution -- users leaving the company, data models being >>>>>>> refactored, >>>>>>> etc. >>>>>>> >>>>>>> So, my thinking was to allow a registry administrator to delete an >>>>>>> object >>>>>>> and at the time of removal specify that all references to the >>>>>>> object >>>>>>> being deleted be targetted/based at/on a new object. The new object >>>>>>> could be an equivalent object, or even a link to an auditable event >>>>>>> which >>>>>>> would allow browsers to at least see that a reference was forcibly >>>>>>> removed. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I understand what you had in mind now as follows: >>>>>> >>>>>> -Allow an object to be deleted even when it has refrences to it >>>>>> >>>>>> -Somehow update references to deleted object to point to its >>>>>> replacement >>>>>> if any or to the AuditableEvent that marks its deletion if it has no >>>>>> replacement. >>>>>> >>>>>> Updating all references would be too costly IMO. The other issue is >>>>>> how to >>>>>> specify replacement object when deleting an object. >>>>>> >>>>>> I think it would be cleaner to simply by default allow an object to >>>>>> be >>>>>> deleted even if it has refrences to it and if define how dangling >>>>>> references should be handles by registry and clients. For example we >>>>>> could >>>>>> say that registry MUST return objects matching a query even if they >>>>>> have >>>>>> dangling references and that it should return >>>>>> UnresolvedReferenceException >>>>>> if client attempts to fetch the object by its reference using a >>>>>> query. As >>>>>> for clients we could say that they should be prepared to handle >>>>>> UnresolvedReferenceException when fetching an object by its >>>>>> reference. >>>>>> >>>>>> I could support above modification to Matt's original suggestion or >>>>>> something along those lines. What do other folks think? >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Matt >>>>>>> Farrukh Najmi wrote: >>>>>>> >>>>>>>> >>>>>>>> Matt, >>>>>>>> >>>>>>>> Please clarify clearly what you intended to convey in this comment. >>>>>>>> Thanks. >>>>>>>> >>>>>>>> Line 1410: "I would prefer if we could allow an overide that says >>>>>>>> "point >>>>>>>> references to this object, such as an auditable event that >>>>>>>> chronicles >>>>>>>> the deletion"." >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> Farrukh >>>>>> >>>>>> >>>>>> To unsubscribe from this mailing list (and be removed from the roster >>>>>> of >>>>>> the OASIS TC), go to >>>>>> http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php. >>>>>> >>>>>> >>>>> >>>>> >>>>> To unsubscribe from this mailing list (and be removed from the roster >>>>> of the OASIS TC), go to >>>>> http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php. >>>>> >>>> >>> >>> >> > > > -- > Regards, > Farrukh > > > To unsubscribe from this mailing list (and be removed from the roster of > the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]