|
| Re: [CDO] modification of cdo objects from a view [message #541262 is a reply to message #541036] |
Sat, 19 June 2010 06:06   |
|
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? 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. 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:
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
Am 18.06.2010 09:33, schrieb Rimvydas Vaidelis:
> 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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
| Re: [CDO] modification of cdo objects from a view [message #541271 is a reply to message #541270] |
Sat, 19 June 2010 09:09 |
|
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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.13002 seconds
] 
Search
Help
Register
Login
Home
