Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [CDO 0.8.0] Performance
[CDO 0.8.0] Performance [message #122918] Fri, 23 May 2008 11:18 Go to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
Hi Eike,

In EMF, everythings is somehow attached from a resource.
However, in our production system, our IStore never update objects
Resources.

Now, that I need to follow the standard, I developped my IStore to update
every objects correctly. However, when we create thousands of objects and
add it to the resource.contents... it starting to get very slow. Also it
needs to go through the list to find out if we already have the items..
etc..etc..

Here my questions:

Can we persist objects without adding it to the resource ?

Could we persist object in a way where objectA.resourceID == resourceA but
resourceA.content will not contains objectA ?
This is in Fact how the result of never updating a Resource.(My previous
IStore)

We could have something like.
CDOTransaction.persist(CDOResource, object);

Do you think it will go against something ?

Thank you.
Re: [CDO 0.8.0] Performance [message #122923 is a reply to message #122918] Fri, 23 May 2008 11:57 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Simon,

Comments below.

Simon McDuff wrote:
> Hi Eike,
>
> In EMF, everythings is somehow attached from a resource.
> However, in our production system, our IStore never update objects
> Resources.
>
> Now, that I need to follow the standard, I developped my IStore to update
> every objects correctly. However, when we create thousands of objects and
> add it to the resource.contents... it starting to get very slow. Also it
> needs to go through the list to find out if we already have the items..
> etc..etc..
>
Maybe you want to create a root contain so the resource has one child
and that child has all the other contents. Then you can manage the list
of all objects in the store itself.
> Here my questions:
>
> Can we persist objects without adding it to the resource ?
>
In general, an object for which eResource() == null can't be persisted.
> Could we persist object in a way where objectA.resourceID == resourceA but
> resourceA.content will not contains objectA ?
> This is in Fact how the result of never updating a Resource.(My previous
> IStore)
>
> We could have something like.
> CDOTransaction.persist(CDOResource, object);
>
> Do you think it will go against something ?
>
Very likely. It's best to meet all the expectations of the framework...
> Thank you.
>
>
>
Re: [CDO 0.8.0] Performance [message #122935 is a reply to message #122923] Fri, 23 May 2008 12:19 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Ed, Simon,

I agree with Ed.
I always recommended to handle the attachment of href'ed objects
explicitely so that it is clear where they're contained.
I believe most strategies to automatically attach referenced but
uncontained objects is not scalable in the best case.
And I only agreed to develop something like a CDOAutoAttacher because it
is completely optional.

Cheers
/Eike


Ed Merks schrieb:
> Simon,
>
> Comments below.
>
> Simon McDuff wrote:
>> Hi Eike,
>>
>> In EMF, everythings is somehow attached from a resource.
>> However, in our production system, our IStore never update objects
>> Resources.
>>
>> Now, that I need to follow the standard, I developped my IStore to
>> update every objects correctly. However, when we create thousands of
>> objects and add it to the resource.contents... it starting to get
>> very slow. Also it needs to go through the list to find out if we
>> already have the items.. etc..etc..
>>
> Maybe you want to create a root contain so the resource has one child
> and that child has all the other contents. Then you can manage the
> list of all objects in the store itself.
>> Here my questions:
>>
>> Can we persist objects without adding it to the resource ?
>>
> In general, an object for which eResource() == null can't be persisted.
>> Could we persist object in a way where objectA.resourceID ==
>> resourceA but resourceA.content will not contains objectA ?
>> This is in Fact how the result of never updating a Resource.(My
>> previous IStore)
>>
>> We could have something like.
>> CDOTransaction.persist(CDOResource, object);
>>
>> Do you think it will go against something ?
>>
> Very likely. It's best to meet all the expectations of the framework...
>> Thank you.
>>
>>
Re: [CDO 0.8.0] Performance [message #122938 is a reply to message #122923] Fri, 23 May 2008 12:43 Go to previous message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
Understand!

So I will create an objects that have a list.
In fact, when you add to this objects you not necessarly add to a list
because it will not keep anything.

My objects will in fact call (IN CDO)
CDOStateMachine.INSTANCE.attach(eObjectToPersist, cdoResource,
(CDOViewImpl)cdoTransaction);

To make it persistent!!

I believe the implementation is cleaner using

CDOTransaction.persist(CDOResource, object);

but I will attach it indirectly.

I think by default it follow the standard.

But by having my special objects doing it .... is the same things that
having CDO framework having it. At the end, you will have an objects with a
collection that you can add to it but not retrieved from it.

"Ed Merks" <merks@ca.ibm.com> a
Re: [CDO 0.8.0] Performance [message #618162 is a reply to message #122918] Fri, 23 May 2008 11:57 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30992
Registered: July 2009
Senior Member
Simon,

Comments below.

Simon McDuff wrote:
> Hi Eike,
>
> In EMF, everythings is somehow attached from a resource.
> However, in our production system, our IStore never update objects
> Resources.
>
> Now, that I need to follow the standard, I developped my IStore to update
> every objects correctly. However, when we create thousands of objects and
> add it to the resource.contents... it starting to get very slow. Also it
> needs to go through the list to find out if we already have the items..
> etc..etc..
>
Maybe you want to create a root contain so the resource has one child
and that child has all the other contents. Then you can manage the list
of all objects in the store itself.
> Here my questions:
>
> Can we persist objects without adding it to the resource ?
>
In general, an object for which eResource() == null can't be persisted.
> Could we persist object in a way where objectA.resourceID == resourceA but
> resourceA.content will not contains objectA ?
> This is in Fact how the result of never updating a Resource.(My previous
> IStore)
>
> We could have something like.
> CDOTransaction.persist(CDOResource, object);
>
> Do you think it will go against something ?
>
Very likely. It's best to meet all the expectations of the framework...
> Thank you.
>
>
>
Re: [CDO 0.8.0] Performance [message #618165 is a reply to message #122923] Fri, 23 May 2008 12:19 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Ed, Simon,

I agree with Ed.
I always recommended to handle the attachment of href'ed objects
explicitely so that it is clear where they're contained.
I believe most strategies to automatically attach referenced but
uncontained objects is not scalable in the best case.
And I only agreed to develop something like a CDOAutoAttacher because it
is completely optional.

Cheers
/Eike


Ed Merks schrieb:
> Simon,
>
> Comments below.
>
> Simon McDuff wrote:
>> Hi Eike,
>>
>> In EMF, everythings is somehow attached from a resource.
>> However, in our production system, our IStore never update objects
>> Resources.
>>
>> Now, that I need to follow the standard, I developped my IStore to
>> update every objects correctly. However, when we create thousands of
>> objects and add it to the resource.contents... it starting to get
>> very slow. Also it needs to go through the list to find out if we
>> already have the items.. etc..etc..
>>
> Maybe you want to create a root contain so the resource has one child
> and that child has all the other contents. Then you can manage the
> list of all objects in the store itself.
>> Here my questions:
>>
>> Can we persist objects without adding it to the resource ?
>>
> In general, an object for which eResource() == null can't be persisted.
>> Could we persist object in a way where objectA.resourceID ==
>> resourceA but resourceA.content will not contains objectA ?
>> This is in Fact how the result of never updating a Resource.(My
>> previous IStore)
>>
>> We could have something like.
>> CDOTransaction.persist(CDOResource, object);
>>
>> Do you think it will go against something ?
>>
> Very likely. It's best to meet all the expectations of the framework...
>> Thank you.
>>
>>


Re: [CDO 0.8.0] Performance [message #618936 is a reply to message #122923] Fri, 23 May 2008 12:43 Go to previous message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
Understand!

So I will create an objects that have a list.
In fact, when you add to this objects you not necessarly add to a list
because it will not keep anything.

My objects will in fact call (IN CDO)
CDOStateMachine.INSTANCE.attach(eObjectToPersist, cdoResource,
(CDOViewImpl)cdoTransaction);

To make it persistent!!

I believe the implementation is cleaner using

CDOTransaction.persist(CDOResource, object);

but I will attach it indirectly.

I think by default it follow the standard.

But by having my special objects doing it .... is the same things that
having CDO framework having it. At the end, you will have an objects with a
collection that you can add to it but not retrieved from it.

"Ed Merks" <merks@ca.ibm.com> a
Previous Topic:[Teneo] Is hibernate.hbm.xml enough
Next Topic:How to create a copy of an EObject with non-null Resource
Goto Forum:
  


Current Time: Sun Mar 29 05:43:40 GMT 2020

Powered by FUDForum. Page generated in 0.01962 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top