[CDO] modification of cdo objects from a view [message #541036] |
Fri, 18 June 2010 03:33  |
Eclipse User |
|
|
|
Hi,
Lets say I have resource R1 and R2 in cdo repository. In resource R1 I
have object R1_O1 that references object R2_O1 from resource R2. R2_O1
is contained by object R2_O2 from resource R2. Lets say somebody loads
resource R2 and deletes the R2_O1. After that if we load the resource R1
and try to access object's R1_O1 property value that referenced object
R2_O1 then we will get ObjectNotFoundException. In CDO 3.0 it is
possible to install CDOStaleReferencePolicy implementation that returns
a copy object initialized from history data.
R1_O1 now references the artificially created object but I want that
R2_O2 also would contain this object. This can be done if cdo objects
retrieved from transaction (I do not want to persist such objects so I
will remove them before committing the transaction).
The problem is that if we will open a view then such code will not work
because cdo prohibits to modify objects from the view. We can add a
constraint that the application should always open transactions but
we also want to have the same functionality with historical data. Since
the CDOAudit is a view then our code will not work.
Maybe somebody has an idea how the problem could be solved with
historical data?
Thanks in advance,
Rimvydas
|
|
|
|
|
Re: [CDO] modification of cdo objects from a view [message #541271 is a reply to message #541270] |
Sat, 19 June 2010 05:09  |
Eclipse User |
|
|
|
Hi Rimvydas,
I see. Regarding your original question, the CDO framework does not
provide any hooks to intercept access to containment references. I
suggest that you create an artificial resource and let your artificial
objects be contained by it. But I don't see a real value in letting them
be contained somewhere at all since you're going to purge all cross
references to them anyway.
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 19.06.2010 10:56, schrieb Rimvydas Vaidelis:
> Hi Eike,
>
> Thank you for the response.
>
> My answers are below.
>
>
> On 2010.06.19 09:06, Eike Stepper wrote:
>> Hi Rimvydas,
>>
>> Just to understand you correctly, you mean if someone deletes an object
>> TARGET and there's an object SOURCE that still references TARGET then
>> you want to undo the delete and recreate a historical version of TARGET
>> while you're *viewing* the repository?
>
> [Rimvydas]: The historical version of the object will be recreated on
> the client side only. On the server side no changes to the data should
> be performed. I.e. client code during traversing the model's graph
> should see these objects as a normal objects. I will have an API that
> will let to check whether an object is restored from history object.
> This is not an undo of deleted object.
>
> I wonder how you want to
>> determine which client is supposed to do the recreation. Maybe you have
>> a good strategy for this decision or you let all clients attempt to
>> commit this change and let all but the first one fail.
>
> [Rimvydas]: Each client will recreate the deleted object but this is
> on client side only. Before commit of the data these recreated objects
> will be removed.
>
> In any case I
>> wold not open a CDOTransaction in the first place, i.e. instead of teh
>> CDOView. I would rather open an additional transaction on the same
>> CDOSession and commit the change from there. If the commit is successful
>> all other views and transactions in the network would see the result
>> some time later.
>>
>> Please note that we're currently working on both finding cross
>> references efficiently through client API and preventing this whole
>> stale reference situation from the beginning:
>
> [Rimvydas]: I think these enhancements are really important but does
> not help us because of our business requirements. We assume deleting
> of an object in one resource and not removing reference to it from
> another resources as normal. Preventing of delete of such objects
> would be too limiting and removing of references to the deleted object
> is not acceptable.
>
>>
>> 300149: Support remote cross referencing with a convenient API on the
>> client and SPI on the server for the stores to implement
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=300149
>>
>> 316434: Provide an option which prevents removal of still referenced
>> objects
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=316434
>>
>> 315407: Stale references can occur if one of two commits deletes a
>> reference target
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=315407
>>
>> Talking about referential integrity this bug we're currently working on
>> might also be intersting for you:
>>
>> 316444: Provide an option to prevent containment cycles
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=316444
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>
> Regards,
>
> Rimvydas
|
|
|
Powered by
FUDForum. Page generated in 0.06429 seconds