|
| Re: [CDO][0.8.0] Give more informations to StoreWriter [message #106354 is a reply to message #106340] |
Mon, 07 January 2008 14:31   |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Simon McDuff schrieb:
> Hi Eike,
>
> I have an object database implementation using CDO.
>
> TO persist my objects in that objects databases some informations such as
> who refer to him will be very useful.
>
Do you mean the user(name)?
> Do you see any way where StoreWriter could have access to the context of the
> transaction before doing anything ?
>
What exactly do you mean by "transaction"
- CDOTransaction at client side?
- IView with type TANSACTION at server side?
- ITransaction<IStoreWriter> like in IStoreWriter.rollback()?
- Transaction of your OODB (must be encapsulated somewhere in your
IStoreWriter implementation)
> I would like to have access to deltas...at the beginning of my transactions
> so I can calculate where my objects will go.
>
Basically I'm not a fan of this because the idea of the storage
framework is a separate layer below the repository layer. I admit that I
was not very strict with this separation myself: interface IStore
extends IRepositoryElement ;-( But we should make the story only worse
if it's absolutely necessary.
> Or to an extension point somewhere in the transaction process... so I can
> talk with my specific IStoreWriter.
>
Can you describe in more detail where exactly you'd like to hook in?
I have the feeling that additional/changed API in the storage framework
could already be sufficient.
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
|
|
|
|
| Re: [CDO][0.8.0] Give more informations to StoreWriter [message #106409 is a reply to message #106368] |
Mon, 07 January 2008 16:19 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Simon McDuff schrieb:
> "Eike Stepper" <stepper@sympedia.de> wrote in message
> news:fltd3c$fvn$1@build.eclipse.org...
>
>> Simon McDuff schrieb:
>>
>>> Hi Eike,
>>>
>>> I have an object database implementation using CDO.
>>>
>>> TO persist my objects in that objects databases some informations such as
>>> who refer to him will be very useful.
>>>
>>>
>> Do you mean the user(name)?
>>
>>
> No I mean if I have an new objectA (transient) that is link with objectB
> (persisted)... I would like to know it so I can persit objectA in a specific
> spot in the database. Object database doesn't have table or such things. It
> is a big memory. When we create an object you tell the system where in the
> memory you would like to persist it. In this case, I would like to put
> objectB close to objectA for performance reason.
>
I think the direction of your "link" makes a big difference. Are you
interested in the referers, particularly the transient ones? I don't
think that it's possible at all to reflect arbitrary referers.
BTW. what's the difference in performance like?
>>> Do you see any way where StoreWriter could have access to the context of
>>> the transaction before doing anything ?
>>>
>>>
>> What exactly do you mean by "transaction"
>> - CDOTransaction at client side?
>> - IView with type TANSACTION at server side?
>> - ITransaction<IStoreWriter> like in IStoreWriter.rollback()?
>> - Transaction of your OODB (must be encapsulated somewhere in your
>> IStoreWriter implementation)
>>
>>
> ITransaction<IStoreWriter>
>
I can see no value in having access to the ITransaction.
May be that's the reason why rollback() doesn't use it either.
I should remove it from the IStoreWriter API.
By "context of the transaction" do you really mean
ITransaction.getContext()?
This method simply returns the IStoreWriter instance which you're in
already.
>>> I would like to have access to deltas...at the beginning of my
>>> transactions so I can calculate where my objects will go.
>>>
>>>
>> Basically I'm not a fan of this because the idea of the storage framework
>> is a separate layer below the repository layer. I admit that I was not
>> very strict with this separation myself: interface IStore extends
>> IRepositoryElement ;-( But we should make the story only worse if it's
>> absolutely necessary.
>>
>
> Storage layer that are object database really needs the context to where to
> put objects. I believed it will be a value for them.
>
Bear with me, I can't follow.
The best discriminators I can imagine of to partition your OODB space in
order to optimize access are
- Repository name (you have it in your store writer via
getStore().getRepository(), although I said that this API is currently
breaking layer separation)
- Resource of the object (you have it in your writeRevision()
implementation via revision.getData().getResourceID(), if you need it in
the new deltas as well we'll possibly have to enhance the deltas)
>>> Or to an extension point somewhere in the transaction process... so I can
>>> talk with my specific IStoreWriter.
>>>
>>>
>> Can you describe in more detail where exactly you'd like to hook in?
>> I have the feeling that additional/changed API in the storage framework
>> could already be sufficient.
>>
> I agree.
>
> A solution could be
>
> void IStoreWriter.begin(ITransactionContext context);
>
> interface ITransactionContext
> {
> getNewPackages();
> getNewResources();
> getNewsObjects();
> getDirtyObjects();
> };
>
I think I begin to understand what you mean by "transaction" and its
"context". You really mean an equivalent of the information in the
client side CDOTransactionImpl, which (at some point in time) is
equivalent to the information in the CommitTransactionIndication.
If so, I'd propose a different solution:
By passing all together the values down before passing them down
separately again I'd rather pass a sort of "revisionDataFinished" event
down to the store writer. Then it's up to your store implementation to
gather all the needed infos (without updating the database) within the
separate data calls and finally do the database update in one chunk at
the end (revisionDataFinished event).
Would that be ok?
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
|
|
|
|
| Re: [CDO][0.8.0] Give more informations to StoreWriter [message #106434 is a reply to message #106420] |
Mon, 07 January 2008 17:36 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Simon McDuff schrieb:
>> If so, I'd propose a different solution:
>> By passing all together the values down before passing them down
>> separately again I'd rather pass a sort of "revisionDataFinished" event
>> down to the store writer. Then it's up to your store implementation to
>> gather all the needed infos (without updating the database) within the
>> separate data calls and finally do the database update in one chunk at the
>> end (revisionDataFinished event).
>>
>> Would that be ok?
>>
>>
>
> Sounds goods...
>
> Right now as we read the data from the stream we call primeNewObjects.
> This would have to change ? Right ? Because I want to make these call after
> I gather all the infos.
>
Funny that it was you who wanted to have the primeNewObject method in
the storage API ;-)
I see your problem but I don't see an easy solution for it. For all your
optimizations I see more and more repository responsibilities walking
down to the store. In the end we can spare it completely and simply pass
an InputStream down to the store. Just joking!
But seriously, can you tell me, how the mapping of tempIDs and metaIDs
should work then?
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
|
|
|
|
|
| Re: [CDO][0.8.0] Give more informations to StoreWriter [message #106474 is a reply to message #106460] |
Mon, 07 January 2008 18:32 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Simon McDuff schrieb:
> Another things...
>
> When we call readNewPackages or readNewResources or readDirtyObjects we do
> not add revisions to the storeWriter ... neither to the RevisionManager.
>
Correct.
> Why we do it with primeNewObject in readNewObjects ?
>
IStoreWriter.primeNewObject is called for new objects and for new
resources. You should know best why we have this method. I changed a lot
of things just because you wanted to have it and I didn't need it for my
store implementation...
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
>
> "Eike Stepper" <stepper@sympedia.de> wrote in message
> news:fltnv4$ci7$2@build.eclipse.org...
>
>> Simon McDuff schrieb:
>>
>>>> If so, I'd propose a different solution:
>>>> By passing all together the values down before passing them down
>>>> separately again I'd rather pass a sort of "revisionDataFinished" event
>>>> down to the store writer. Then it's up to your store implementation to
>>>> gather all the needed infos (without updating the database) within the
>>>> separate data calls and finally do the database update in one chunk at
>>>> the end (revisionDataFinished event).
>>>>
>>>> Would that be ok?
>>>>
>>>>
>>>>
>>> Sounds goods...
>>>
>>> Right now as we read the data from the stream we call primeNewObjects.
>>> This would have to change ? Right ? Because I want to make these call
>>> after I gather all the infos.
>>>
>>>
>> Funny that it was you who wanted to have the primeNewObject method in the
>> storage API ;-)
>> I see your problem but I don't see an easy solution for it. For all your
>> optimizations I see more and more repository responsibilities walking down
>> to the store. In the end we can spare it completely and simply pass an
>> InputStream down to the store. Just joking!
>>
>> But seriously, can you tell me, how the mapping of tempIDs and metaIDs
>> should work then?
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>
>
>
|
|
|
| Re: [CDO][0.8.0] Give more informations to StoreWriter [message #106490 is a reply to message #106447] |
Mon, 07 January 2008 18:39 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Simon,
I suggest that you open an enhancement request and I'll see if I can
come up with a different design.
Please note that I'll be absent from 9th to 16th.
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
Simon McDuff schrieb:
> "Eike Stepper" <stepper@sympedia.de> wrote in message
> news:fltnv4$ci7$2@build.eclipse.org...
>
>> Simon McDuff schrieb:
>>
>>>> If so, I'd propose a different solution:
>>>> By passing all together the values down before passing them down
>>>> separately again I'd rather pass a sort of "revisionDataFinished" event
>>>> down to the store writer. Then it's up to your store implementation to
>>>> gather all the needed infos (without updating the database) within the
>>>> separate data calls and finally do the database update in one chunk at
>>>> the end (revisionDataFinished event).
>>>>
>>>> Would that be ok?
>>>>
>>>>
>>>>
>>> Sounds goods...
>>>
>>> Right now as we read the data from the stream we call primeNewObjects.
>>> This would have to change ? Right ? Because I want to make these call
>>> after I gather all the infos.
>>>
>>>
> I don't have a problem with primeNewObjects... it is when we call it that I
> have a problem with.
> We seems to mix up serialization and processing at many places.
>
> Should not we unserialize data... and then apply changes to have a real
> transaction scope.
> Right now we do both of them at the same time.
> I would like to see a separation between two different processes.
> It is strange because we create ITransaction.. and in fact we already did
> apply some changes to the graph.
>
> If we do all modifications after reading from the stream.. it will be easier
> to manage stuff in my StoreWriter.
>
>
>> Funny that it was you who wanted to have the primeNewObject method in the
>> storage API ;-)
>> I see your problem but I don't see an easy solution for it. For all your
>> optimizations I see more and more repository responsibilities walking down
>> to the store. In the end we can spare it completely and simply pass an
>> InputStream down to the store. Just joking!
>>
>> But seriously, can you tell me, how the mapping of tempIDs and metaIDs
>> should work then?
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>
>
>
|
|
|
|
| Re: [CDO][0.8.0] Give more informations to StoreWriter [message #106514 is a reply to message #106502] |
Mon, 07 January 2008 19:16 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Simon McDuff schrieb:
> "Eike Stepper" <stepper@sympedia.de> wrote in message
> news:fltr7m$ci7$3@build.eclipse.org...
>
>> Simon McDuff schrieb:
>>
>>> Another things...
>>>
>>> When we call readNewPackages or readNewResources or readDirtyObjects we
>>> do not add revisions to the storeWriter ... neither to the
>>> RevisionManager.
>>>
>>>
>> Correct.
>>
>>
>>> Why we do it with primeNewObject in readNewObjects ?
>>>
>>>
>> IStoreWriter.primeNewObject is called for new objects and for new
>> resources. You should know best why we have this method. I changed a lot
>> of things just because you wanted to have it and I didn't need it for my
>> store implementation...
>>
>>
> The only things I asked was to change the responsability of the ID from
> CDOID newID = getRepository().getNextCDOID();
>
> to
>
> CDOID newID = storeWriter.primeNewObject(revision.getCDOClass());
>
> Not that many changes.
>
> If you want to integrate with other databases like Hibernate that have more
> accessor than CDO you have no choice to delegate the responsability to the
> store. Otherwise you performance will not be very good.
>
> Don't you see the advantage ?
>
I didn't say that this change was bad. I remember well that discussion,
also with respect to possible store-controlled CDOID formats.
I only wanted to say that before this change the store was not in the
game at this time (readNewObjects).
But that's not important now. Let's see if something cool comes out of
your request: https://bugs.eclipse.org/bugs/show_bug.cgi?id=214526
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
>
>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>
>>> "Eike Stepper" <stepper@sympedia.de> wrote in message
>>> news:fltnv4$ci7$2@build.eclipse.org...
>>>
>>>
>>>> Simon McDuff schrieb:
>>>>
>>>>
>>>>>> If so, I'd propose a different solution:
>>>>>> By passing all together the values down before passing them down
>>>>>> separately again I'd rather pass a sort of "revisionDataFinished"
>>>>>> event down to the store writer. Then it's up to your store
>>>>>> implementation to gather all the needed infos (without updating the
>>>>>> database) within the separate data calls and finally do the database
>>>>>> update in one chunk at the end (revisionDataFinished event).
>>>>>>
>>>>>> Would that be ok?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Sounds goods...
>>>>>
>>>>> Right now as we read the data from the stream we call primeNewObjects.
>>>>> This would have to change ? Right ? Because I want to make these call
>>>>> after I gather all the infos.
>>>>>
>>>>>
>>>>>
>>>> Funny that it was you who wanted to have the primeNewObject method in
>>>> the storage API ;-)
>>>> I see your problem but I don't see an easy solution for it. For all your
>>>> optimizations I see more and more repository responsibilities walking
>>>> down to the store. In the end we can spare it completely and simply pass
>>>> an InputStream down to the store. Just joking!
>>>>
>>>> But seriously, can you tell me, how the mapping of tempIDs and metaIDs
>>>> should work then?
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/CDO
>>>> http://wiki.eclipse.org/Net4j
>>>>
>>>>
>>>>
>>>
>>>
>
>
>
|
|
|
|
| Re: [CDO][0.8.0] Give more informations to StoreWriter [message #106630 is a reply to message #106528] |
Tue, 08 January 2008 22:39 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Simon McDuff schrieb:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=214526
> You are going in vacation again!! :-) Lucky you!!!
>
Just a week in NY, my friend found a very cheap flight ;-)
CU
/Eike
> "Eike Stepper" <stepper@sympedia.de> wrote in message
> news:fltrkp$ci7$4@build.eclipse.org...
>
>> Simon,
>>
>> I suggest that you open an enhancement request and I'll see if I can come
>> up with a different design.
>> Please note that I'll be absent from 9th to 16th.
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>> Simon McDuff schrieb:
>>
>>> "Eike Stepper" <stepper@sympedia.de> wrote in message
>>> news:fltnv4$ci7$2@build.eclipse.org...
>>>
>>>
>>>> Simon McDuff schrieb:
>>>>
>>>>
>>>>>> If so, I'd propose a different solution:
>>>>>> By passing all together the values down before passing them down
>>>>>> separately again I'd rather pass a sort of "revisionDataFinished"
>>>>>> event down to the store writer. Then it's up to your store
>>>>>> implementation to gather all the needed infos (without updating the
>>>>>> database) within the separate data calls and finally do the database
>>>>>> update in one chunk at the end (revisionDataFinished event).
>>>>>>
>>>>>> Would that be ok?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Sounds goods...
>>>>>
>>>>> Right now as we read the data from the stream we call primeNewObjects.
>>>>> This would have to change ? Right ? Because I want to make these call
>>>>> after I gather all the infos.
>>>>>
>>>>>
>>>>>
>>> I don't have a problem with primeNewObjects... it is when we call it
>>> that I have a problem with.
>>> We seems to mix up serialization and processing at many places.
>>>
>>> Should not we unserialize data... and then apply changes to have a real
>>> transaction scope.
>>> Right now we do both of them at the same time.
>>> I would like to see a separation between two different processes.
>>> It is strange because we create ITransaction.. and in fact we already did
>>> apply some changes to the graph.
>>>
>>> If we do all modifications after reading from the stream.. it will be
>>> easier to manage stuff in my StoreWriter.
>>>
>>>
>>>
>>>> Funny that it was you who wanted to have the primeNewObject method in
>>>> the storage API ;-)
>>>> I see your problem but I don't see an easy solution for it. For all your
>>>> optimizations I see more and more repository responsibilities walking
>>>> down to the store. In the end we can spare it completely and simply pass
>>>> an InputStream down to the store. Just joking!
>>>>
>>>> But seriously, can you tell me, how the mapping of tempIDs and metaIDs
>>>> should work then?
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/CDO
>>>> http://wiki.eclipse.org/Net4j
>>>>
>>>>
>>>>
>>>
>>>
>
>
>
|
|
|
| Re: [CDO][0.8.0] Give more informations to StoreWriter [message #613945 is a reply to message #106340] |
Mon, 07 January 2008 14:31 |
|
Simon McDuff schrieb:
> Hi Eike,
>
> I have an object database implementation using CDO.
>
> TO persist my objects in that objects databases some informations such as
> who refer to him will be very useful.
>
Do you mean the user(name)?
> Do you see any way where StoreWriter could have access to the context of the
> transaction before doing anything ?
>
What exactly do you mean by "transaction"
- CDOTransaction at client side?
- IView with type TANSACTION at server side?
- ITransaction<IStoreWriter> like in IStoreWriter.rollback()?
- Transaction of your OODB (must be encapsulated somewhere in your
IStoreWriter implementation)
> I would like to have access to deltas...at the beginning of my transactions
> so I can calculate where my objects will go.
>
Basically I'm not a fan of this because the idea of the storage
framework is a separate layer below the repository layer. I admit that I
was not very strict with this separation myself: interface IStore
extends IRepositoryElement ;-( But we should make the story only worse
if it's absolutely necessary.
> Or to an extension point somewhere in the transaction process... so I can
> talk with my specific IStoreWriter.
>
Can you describe in more detail where exactly you'd like to hook in?
I have the feeling that additional/changed API in the storage framework
could already be sufficient.
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
| Re: [CDO][0.8.0] Give more informations to StoreWriter [message #613954 is a reply to message #106368] |
Mon, 07 January 2008 16:19 |
|
Simon McDuff schrieb:
> "Eike Stepper" <stepper@sympedia.de> wrote in message
> news:fltd3c$fvn$1@build.eclipse.org...
>
>> Simon McDuff schrieb:
>>
>>> Hi Eike,
>>>
>>> I have an object database implementation using CDO.
>>>
>>> TO persist my objects in that objects databases some informations such as
>>> who refer to him will be very useful.
>>>
>>>
>> Do you mean the user(name)?
>>
>>
> No I mean if I have an new objectA (transient) that is link with objectB
> (persisted)... I would like to know it so I can persit objectA in a specific
> spot in the database. Object database doesn't have table or such things. It
> is a big memory. When we create an object you tell the system where in the
> memory you would like to persist it. In this case, I would like to put
> objectB close to objectA for performance reason.
>
I think the direction of your "link" makes a big difference. Are you
interested in the referers, particularly the transient ones? I don't
think that it's possible at all to reflect arbitrary referers.
BTW. what's the difference in performance like?
>>> Do you see any way where StoreWriter could have access to the context of
>>> the transaction before doing anything ?
>>>
>>>
>> What exactly do you mean by "transaction"
>> - CDOTransaction at client side?
>> - IView with type TANSACTION at server side?
>> - ITransaction<IStoreWriter> like in IStoreWriter.rollback()?
>> - Transaction of your OODB (must be encapsulated somewhere in your
>> IStoreWriter implementation)
>>
>>
> ITransaction<IStoreWriter>
>
I can see no value in having access to the ITransaction.
May be that's the reason why rollback() doesn't use it either.
I should remove it from the IStoreWriter API.
By "context of the transaction" do you really mean
ITransaction.getContext()?
This method simply returns the IStoreWriter instance which you're in
already.
>>> I would like to have access to deltas...at the beginning of my
>>> transactions so I can calculate where my objects will go.
>>>
>>>
>> Basically I'm not a fan of this because the idea of the storage framework
>> is a separate layer below the repository layer. I admit that I was not
>> very strict with this separation myself: interface IStore extends
>> IRepositoryElement ;-( But we should make the story only worse if it's
>> absolutely necessary.
>>
>
> Storage layer that are object database really needs the context to where to
> put objects. I believed it will be a value for them.
>
Bear with me, I can't follow.
The best discriminators I can imagine of to partition your OODB space in
order to optimize access are
- Repository name (you have it in your store writer via
getStore().getRepository(), although I said that this API is currently
breaking layer separation)
- Resource of the object (you have it in your writeRevision()
implementation via revision.getData().getResourceID(), if you need it in
the new deltas as well we'll possibly have to enhance the deltas)
>>> Or to an extension point somewhere in the transaction process... so I can
>>> talk with my specific IStoreWriter.
>>>
>>>
>> Can you describe in more detail where exactly you'd like to hook in?
>> I have the feeling that additional/changed API in the storage framework
>> could already be sufficient.
>>
> I agree.
>
> A solution could be
>
> void IStoreWriter.begin(ITransactionContext context);
>
> interface ITransactionContext
> {
> getNewPackages();
> getNewResources();
> getNewsObjects();
> getDirtyObjects();
> };
>
I think I begin to understand what you mean by "transaction" and its
"context". You really mean an equivalent of the information in the
client side CDOTransactionImpl, which (at some point in time) is
equivalent to the information in the CommitTransactionIndication.
If so, I'd propose a different solution:
By passing all together the values down before passing them down
separately again I'd rather pass a sort of "revisionDataFinished" event
down to the store writer. Then it's up to your store implementation to
gather all the needed infos (without updating the database) within the
separate data calls and finally do the database update in one chunk at
the end (revisionDataFinished event).
Would that be ok?
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
| Re: [CDO][0.8.0] Give more informations to StoreWriter [message #613957 is a reply to message #106420] |
Mon, 07 January 2008 17:36 |
|
Simon McDuff schrieb:
>> If so, I'd propose a different solution:
>> By passing all together the values down before passing them down
>> separately again I'd rather pass a sort of "revisionDataFinished" event
>> down to the store writer. Then it's up to your store implementation to
>> gather all the needed infos (without updating the database) within the
>> separate data calls and finally do the database update in one chunk at the
>> end (revisionDataFinished event).
>>
>> Would that be ok?
>>
>>
>
> Sounds goods...
>
> Right now as we read the data from the stream we call primeNewObjects.
> This would have to change ? Right ? Because I want to make these call after
> I gather all the infos.
>
Funny that it was you who wanted to have the primeNewObject method in
the storage API ;-)
I see your problem but I don't see an easy solution for it. For all your
optimizations I see more and more repository responsibilities walking
down to the store. In the end we can spare it completely and simply pass
an InputStream down to the store. Just joking!
But seriously, can you tell me, how the mapping of tempIDs and metaIDs
should work then?
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
| Re: [CDO][0.8.0] Give more informations to StoreWriter [message #613960 is a reply to message #106460] |
Mon, 07 January 2008 18:32 |
|
Simon McDuff schrieb:
> Another things...
>
> When we call readNewPackages or readNewResources or readDirtyObjects we do
> not add revisions to the storeWriter ... neither to the RevisionManager.
>
Correct.
> Why we do it with primeNewObject in readNewObjects ?
>
IStoreWriter.primeNewObject is called for new objects and for new
resources. You should know best why we have this method. I changed a lot
of things just because you wanted to have it and I didn't need it for my
store implementation...
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
>
> "Eike Stepper" <stepper@sympedia.de> wrote in message
> news:fltnv4$ci7$2@build.eclipse.org...
>
>> Simon McDuff schrieb:
>>
>>>> If so, I'd propose a different solution:
>>>> By passing all together the values down before passing them down
>>>> separately again I'd rather pass a sort of "revisionDataFinished" event
>>>> down to the store writer. Then it's up to your store implementation to
>>>> gather all the needed infos (without updating the database) within the
>>>> separate data calls and finally do the database update in one chunk at
>>>> the end (revisionDataFinished event).
>>>>
>>>> Would that be ok?
>>>>
>>>>
>>>>
>>> Sounds goods...
>>>
>>> Right now as we read the data from the stream we call primeNewObjects.
>>> This would have to change ? Right ? Because I want to make these call
>>> after I gather all the infos.
>>>
>>>
>> Funny that it was you who wanted to have the primeNewObject method in the
>> storage API ;-)
>> I see your problem but I don't see an easy solution for it. For all your
>> optimizations I see more and more repository responsibilities walking down
>> to the store. In the end we can spare it completely and simply pass an
>> InputStream down to the store. Just joking!
>>
>> But seriously, can you tell me, how the mapping of tempIDs and metaIDs
>> should work then?
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO][0.8.0] Give more informations to StoreWriter [message #613961 is a reply to message #106447] |
Mon, 07 January 2008 18:39 |
|
Simon,
I suggest that you open an enhancement request and I'll see if I can
come up with a different design.
Please note that I'll be absent from 9th to 16th.
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
Simon McDuff schrieb:
> "Eike Stepper" <stepper@sympedia.de> wrote in message
> news:fltnv4$ci7$2@build.eclipse.org...
>
>> Simon McDuff schrieb:
>>
>>>> If so, I'd propose a different solution:
>>>> By passing all together the values down before passing them down
>>>> separately again I'd rather pass a sort of "revisionDataFinished" event
>>>> down to the store writer. Then it's up to your store implementation to
>>>> gather all the needed infos (without updating the database) within the
>>>> separate data calls and finally do the database update in one chunk at
>>>> the end (revisionDataFinished event).
>>>>
>>>> Would that be ok?
>>>>
>>>>
>>>>
>>> Sounds goods...
>>>
>>> Right now as we read the data from the stream we call primeNewObjects.
>>> This would have to change ? Right ? Because I want to make these call
>>> after I gather all the infos.
>>>
>>>
> I don't have a problem with primeNewObjects... it is when we call it that I
> have a problem with.
> We seems to mix up serialization and processing at many places.
>
> Should not we unserialize data... and then apply changes to have a real
> transaction scope.
> Right now we do both of them at the same time.
> I would like to see a separation between two different processes.
> It is strange because we create ITransaction.. and in fact we already did
> apply some changes to the graph.
>
> If we do all modifications after reading from the stream.. it will be easier
> to manage stuff in my StoreWriter.
>
>
>> Funny that it was you who wanted to have the primeNewObject method in the
>> storage API ;-)
>> I see your problem but I don't see an easy solution for it. For all your
>> optimizations I see more and more repository responsibilities walking down
>> to the store. In the end we can spare it completely and simply pass an
>> InputStream down to the store. Just joking!
>>
>> But seriously, can you tell me, how the mapping of tempIDs and metaIDs
>> should work then?
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
| Re: [CDO][0.8.0] Give more informations to StoreWriter [message #613963 is a reply to message #106502] |
Mon, 07 January 2008 19:16 |
|
Simon McDuff schrieb:
> "Eike Stepper" <stepper@sympedia.de> wrote in message
> news:fltr7m$ci7$3@build.eclipse.org...
>
>> Simon McDuff schrieb:
>>
>>> Another things...
>>>
>>> When we call readNewPackages or readNewResources or readDirtyObjects we
>>> do not add revisions to the storeWriter ... neither to the
>>> RevisionManager.
>>>
>>>
>> Correct.
>>
>>
>>> Why we do it with primeNewObject in readNewObjects ?
>>>
>>>
>> IStoreWriter.primeNewObject is called for new objects and for new
>> resources. You should know best why we have this method. I changed a lot
>> of things just because you wanted to have it and I didn't need it for my
>> store implementation...
>>
>>
> The only things I asked was to change the responsability of the ID from
> CDOID newID = getRepository().getNextCDOID();
>
> to
>
> CDOID newID = storeWriter.primeNewObject(revision.getCDOClass());
>
> Not that many changes.
>
> If you want to integrate with other databases like Hibernate that have more
> accessor than CDO you have no choice to delegate the responsability to the
> store. Otherwise you performance will not be very good.
>
> Don't you see the advantage ?
>
I didn't say that this change was bad. I remember well that discussion,
also with respect to possible store-controlled CDOID formats.
I only wanted to say that before this change the store was not in the
game at this time (readNewObjects).
But that's not important now. Let's see if something cool comes out of
your request: https://bugs.eclipse.org/bugs/show_bug.cgi?id=214526
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
>
>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>
>>> "Eike Stepper" <stepper@sympedia.de> wrote in message
>>> news:fltnv4$ci7$2@build.eclipse.org...
>>>
>>>
>>>> Simon McDuff schrieb:
>>>>
>>>>
>>>>>> If so, I'd propose a different solution:
>>>>>> By passing all together the values down before passing them down
>>>>>> separately again I'd rather pass a sort of "revisionDataFinished"
>>>>>> event down to the store writer. Then it's up to your store
>>>>>> implementation to gather all the needed infos (without updating the
>>>>>> database) within the separate data calls and finally do the database
>>>>>> update in one chunk at the end (revisionDataFinished event).
>>>>>>
>>>>>> Would that be ok?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Sounds goods...
>>>>>
>>>>> Right now as we read the data from the stream we call primeNewObjects.
>>>>> This would have to change ? Right ? Because I want to make these call
>>>>> after I gather all the infos.
>>>>>
>>>>>
>>>>>
>>>> Funny that it was you who wanted to have the primeNewObject method in
>>>> the storage API ;-)
>>>> I see your problem but I don't see an easy solution for it. For all your
>>>> optimizations I see more and more repository responsibilities walking
>>>> down to the store. In the end we can spare it completely and simply pass
>>>> an InputStream down to the store. Just joking!
>>>>
>>>> But seriously, can you tell me, how the mapping of tempIDs and metaIDs
>>>> should work then?
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/CDO
>>>> http://wiki.eclipse.org/Net4j
>>>>
>>>>
>>>>
>>>
>>>
>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
| Re: [CDO][0.8.0] Give more informations to StoreWriter [message #613971 is a reply to message #106528] |
Tue, 08 January 2008 22:39 |
|
Simon McDuff schrieb:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=214526
> You are going in vacation again!! :-) Lucky you!!!
>
Just a week in NY, my friend found a very cheap flight ;-)
CU
/Eike
> "Eike Stepper" <stepper@sympedia.de> wrote in message
> news:fltrkp$ci7$4@build.eclipse.org...
>
>> Simon,
>>
>> I suggest that you open an enhancement request and I'll see if I can come
>> up with a different design.
>> Please note that I'll be absent from 9th to 16th.
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>> Simon McDuff schrieb:
>>
>>> "Eike Stepper" <stepper@sympedia.de> wrote in message
>>> news:fltnv4$ci7$2@build.eclipse.org...
>>>
>>>
>>>> Simon McDuff schrieb:
>>>>
>>>>
>>>>>> If so, I'd propose a different solution:
>>>>>> By passing all together the values down before passing them down
>>>>>> separately again I'd rather pass a sort of "revisionDataFinished"
>>>>>> event down to the store writer. Then it's up to your store
>>>>>> implementation to gather all the needed infos (without updating the
>>>>>> database) within the separate data calls and finally do the database
>>>>>> update in one chunk at the end (revisionDataFinished event).
>>>>>>
>>>>>> Would that be ok?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Sounds goods...
>>>>>
>>>>> Right now as we read the data from the stream we call primeNewObjects.
>>>>> This would have to change ? Right ? Because I want to make these call
>>>>> after I gather all the infos.
>>>>>
>>>>>
>>>>>
>>> I don't have a problem with primeNewObjects... it is when we call it
>>> that I have a problem with.
>>> We seems to mix up serialization and processing at many places.
>>>
>>> Should not we unserialize data... and then apply changes to have a real
>>> transaction scope.
>>> Right now we do both of them at the same time.
>>> I would like to see a separation between two different processes.
>>> It is strange because we create ITransaction.. and in fact we already did
>>> apply some changes to the graph.
>>>
>>> If we do all modifications after reading from the stream.. it will be
>>> easier to manage stuff in my StoreWriter.
>>>
>>>
>>>
>>>> Funny that it was you who wanted to have the primeNewObject method in
>>>> the storage API ;-)
>>>> I see your problem but I don't see an easy solution for it. For all your
>>>> optimizations I see more and more repository responsibilities walking
>>>> down to the store. In the end we can spare it completely and simply pass
>>>> an InputStream down to the store. Just joking!
>>>>
>>>> But seriously, can you tell me, how the mapping of tempIDs and metaIDs
>>>> should work then?
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/CDO
>>>> http://wiki.eclipse.org/Net4j
>>>>
>>>>
>>>>
>>>
>>>
>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
] 
Search
Help
Register
Login
Home
