Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] Version handling
[CDO] Version handling [message #423249] Thu, 25 September 2008 13:55 Go to next message
Eclipse UserFriend
Originally posted by: andras.okros.optxware.com

Hi group,

We have been testing the CDO for a while now, and it seems to be a
promising technology.

However we found one missing feature, which could be useful during
modeling; some kind of version handling mechanism. In plain EMF it is
not that important, as the instance files can be put into cvs/svn etc..
However with CDO we don't see any simple method like that.

Is there any ongoing work about this? Or some solution, which we overlooked?

Thanks a lot in advance
András
Re: [CDO] Version handling [message #423255 is a reply to message #423249] Thu, 25 September 2008 14:26 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6465
Registered: July 2009
Senior Member
András Ökrös schrieb:
> Hi group,
>
> We have been testing the CDO for a while now, and it seems to be a
> promising technology.
Thank you ;-)

>
> However we found one missing feature, which could be useful during
> modeling; some kind of version handling mechanism. In plain EMF it is
> not that important, as the instance files can be put into cvs/svn
> etc.. However with CDO we don't see any simple method like that.
>
> Is there any ongoing work about this? Or some solution, which we
> overlooked?
I think, yes, depending on what you understand of "some kind of version
handling mechanism" ;-)
CDO has always had and still has what we call "auditing" views.
A CDOAudit is a special type of CDOView with a configurable timeStamp
that judges what you're seeing in the view. Or better "when".
Auditing must be supported by the used store and enabled by the repository.
Then clients can simply call session.openAudit(timeStamp) to see an old
state of the object graph.
I've just added the CDOAudit.setTimeStamp() method, so you might want to
try the latest sources.

I would appreciate when you evaluate this feature and tell me if it
suits your needs.

Cheers
/Eike


Re: [CDO] Version handling [message #423272 is a reply to message #423255] Thu, 25 September 2008 16:33 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: andras.okros.optxware.com

Hi Eike,

I tried now with latest source, and the CDOAudit works fine. Actually I
was a bit surprised, as I did not set anything in the mysql database.
This raises my first concern, how reliable this solution is? If I
understand correctly, it is only depend on the audit mechanisms of the
underlying DB?

Actually what I'm still missing regarding the "version control" is two
small enhacements;
- Possiblity to save "tagged" versions. (So anytime I want, I could
create one, with some sort of a string comment.) Actualy if audit works
well it seems to be quite an easy task to write a new UI extension,
which allows to save timestamp informations with comments.
- Some sort of rollback method in an audit could be useful (overwriting
the current version, with the version in the audit). At this moment I
can by-pass it by exporting the audit's information into an xml, and
load it back into a transaction.

Cheers,
András

Eike Stepper írta:
> András Ökrös schrieb:
>> Hi group,
>>
>> We have been testing the CDO for a while now, and it seems to be a
>> promising technology.
> Thank you ;-)
>
>>
>> However we found one missing feature, which could be useful during
>> modeling; some kind of version handling mechanism. In plain EMF it is
>> not that important, as the instance files can be put into cvs/svn
>> etc.. However with CDO we don't see any simple method like that.
>>
>> Is there any ongoing work about this? Or some solution, which we
>> overlooked?
> I think, yes, depending on what you understand of "some kind of version
> handling mechanism" ;-)
> CDO has always had and still has what we call "auditing" views.
> A CDOAudit is a special type of CDOView with a configurable timeStamp
> that judges what you're seeing in the view. Or better "when".
> Auditing must be supported by the used store and enabled by the repository.
> Then clients can simply call session.openAudit(timeStamp) to see an old
> state of the object graph.
> I've just added the CDOAudit.setTimeStamp() method, so you might want to
> try the latest sources.
>
> I would appreciate when you evaluate this feature and tell me if it
> suits your needs.
>
> Cheers
> /Eike
Re: [CDO] Version handling [message #423278 is a reply to message #423272] Thu, 25 September 2008 20:31 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6465
Registered: July 2009
Senior Member
András Ökrös schrieb:
> Hi Eike,
>
> I tried now with latest source, and the CDOAudit works fine. Actually
> I was a bit surprised, as I did not set anything in the mysql
> database. This raises my first concern, how reliable this solution is?
> If I understand correctly, it is only depend on the audit mechanisms
> of the underlying DB?
No, it depends on the mechanisms of the backend-adapter (IStore) and the
configuration of the repository. The implementor of a backend-adapter
can decide to use a backend mechansim (if available), implement an own
mechanism or just don't offer auditing. The DBStore for example supports
auditing while the HibernateStore currently does not. Since the DBStore
is database (vendor) agnostic it implements auditing support on its own.

What exactly are your reliablility concerns?

>
> Actually what I'm still missing regarding the "version control" is two
> small enhacements;
> - Possiblity to save "tagged" versions. (So anytime I want, I could
> create one, with some sort of a string comment.) Actualy if audit
> works well it seems to be quite an easy task to write a new UI
> extension, which allows to save timestamp informations with comments.
Yes, this would make a nice little feature request ;-)
In fact it would be comparingly easy to associate a point in time with a
name and optional comment.

> - Some sort of rollback method in an audit could be useful
> (overwriting the current version, with the version in the audit). At
> this moment I can by-pass it by exporting the audit's information into
> an xml, and load it back into a transaction.
Although this has occasionally been requested I was always reluctant to
the idea of adding a mechanism that partially rolls back the object
graph of the repository (without going through a normal transaction).
Usually single objects in such an object graph can't be seen in
isolation and, as a consequence, not modified in isolation. I think your
approach of using an audit view in combination with a transaction is the
best you can do. You'd even not need an intermediary XML file. Just
detach objects from the audit view and attach them to the transaction
before committing it.

Cheers
/Eike

>
> Cheers,
> András
>
> Eike Stepper írta:
>> András Ökrös schrieb:
>>> Hi group,
>>>
>>> We have been testing the CDO for a while now, and it seems to be a
>>> promising technology.
>> Thank you ;-)
>>
>>>
>>> However we found one missing feature, which could be useful during
>>> modeling; some kind of version handling mechanism. In plain EMF it
>>> is not that important, as the instance files can be put into cvs/svn
>>> etc.. However with CDO we don't see any simple method like that.
>>>
>>> Is there any ongoing work about this? Or some solution, which we
>>> overlooked?
>> I think, yes, depending on what you understand of "some kind of
>> version handling mechanism" ;-)
>> CDO has always had and still has what we call "auditing" views.
>> A CDOAudit is a special type of CDOView with a configurable timeStamp
>> that judges what you're seeing in the view. Or better "when".
>> Auditing must be supported by the used store and enabled by the
>> repository.
>> Then clients can simply call session.openAudit(timeStamp) to see an
>> old state of the object graph.
>> I've just added the CDOAudit.setTimeStamp() method, so you might want
>> to try the latest sources.
>>
>> I would appreciate when you evaluate this feature and tell me if it
>> suits your needs.
>>
>> Cheers
>> /Eike


Re: [CDO] Version handling [message #423357 is a reply to message #423278] Mon, 29 September 2008 13:37 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: andras.okros.optxware.com

Hi Eike,

Thanks for the clarification regarding the audit mechanisms. I don't
have any special reliability concerns, just wanted to know which part of
the code is responsible for the "audit-handling". (We have some ongoing
projects, and it is good to know, that various databases can be used, if
the backend-adapter is the DBStore...)

Cheers,
András

Eike Stepper írta:
> András Ökrös schrieb:
>> Hi Eike,
>>
>> I tried now with latest source, and the CDOAudit works fine. Actually
>> I was a bit surprised, as I did not set anything in the mysql
>> database. This raises my first concern, how reliable this solution is?
>> If I understand correctly, it is only depend on the audit mechanisms
>> of the underlying DB?
> No, it depends on the mechanisms of the backend-adapter (IStore) and the
> configuration of the repository. The implementor of a backend-adapter
> can decide to use a backend mechansim (if available), implement an own
> mechanism or just don't offer auditing. The DBStore for example supports
> auditing while the HibernateStore currently does not. Since the DBStore
> is database (vendor) agnostic it implements auditing support on its own.
>
> What exactly are your reliablility concerns?
>
>>
>> Actually what I'm still missing regarding the "version control" is two
>> small enhacements;
>> - Possiblity to save "tagged" versions. (So anytime I want, I could
>> create one, with some sort of a string comment.) Actualy if audit
>> works well it seems to be quite an easy task to write a new UI
>> extension, which allows to save timestamp informations with comments.
> Yes, this would make a nice little feature request ;-)
> In fact it would be comparingly easy to associate a point in time with a
> name and optional comment.
>
>> - Some sort of rollback method in an audit could be useful
>> (overwriting the current version, with the version in the audit). At
>> this moment I can by-pass it by exporting the audit's information into
>> an xml, and load it back into a transaction.
> Although this has occasionally been requested I was always reluctant to
> the idea of adding a mechanism that partially rolls back the object
> graph of the repository (without going through a normal transaction).
> Usually single objects in such an object graph can't be seen in
> isolation and, as a consequence, not modified in isolation. I think your
> approach of using an audit view in combination with a transaction is the
> best you can do. You'd even not need an intermediary XML file. Just
> detach objects from the audit view and attach them to the transaction
> before committing it.
>
> Cheers
> /Eike
>
>>
>> Cheers,
>> András
>>
>> Eike Stepper írta:
>>> András Ökrös schrieb:
>>>> Hi group,
>>>>
>>>> We have been testing the CDO for a while now, and it seems to be a
>>>> promising technology.
>>> Thank you ;-)
>>>
>>>>
>>>> However we found one missing feature, which could be useful during
>>>> modeling; some kind of version handling mechanism. In plain EMF it
>>>> is not that important, as the instance files can be put into cvs/svn
>>>> etc.. However with CDO we don't see any simple method like that.
>>>>
>>>> Is there any ongoing work about this? Or some solution, which we
>>>> overlooked?
>>> I think, yes, depending on what you understand of "some kind of
>>> version handling mechanism" ;-)
>>> CDO has always had and still has what we call "auditing" views.
>>> A CDOAudit is a special type of CDOView with a configurable timeStamp
>>> that judges what you're seeing in the view. Or better "when".
>>> Auditing must be supported by the used store and enabled by the
>>> repository.
>>> Then clients can simply call session.openAudit(timeStamp) to see an
>>> old state of the object graph.
>>> I've just added the CDOAudit.setTimeStamp() method, so you might want
>>> to try the latest sources.
>>>
>>> I would appreciate when you evaluate this feature and tell me if it
>>> suits your needs.
>>>
>>> Cheers
>>> /Eike
Re: [CDO] Version handling [message #423358 is a reply to message #423357] Mon, 29 September 2008 13:45 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6465
Registered: July 2009
Senior Member
András Ökrös schrieb:
> Hi Eike,
>
> Thanks for the clarification regarding the audit mechanisms. I don't
> have any special reliability concerns, just wanted to know which part
> of the code is responsible for the "audit-handling".
Ah yes, the general auditing feature is inherent to the whole design of
CDO, from the client down to the repository and the stores.

Cheers
/Eike



> (We have some ongoing projects, and it is good to know, that various
> databases can be used, if the backend-adapter is the DBStore...)
>
> Cheers,
> András
>
> Eike Stepper írta:
>> András Ökrös schrieb:
>>> Hi Eike,
>>>
>>> I tried now with latest source, and the CDOAudit works fine.
>>> Actually I was a bit surprised, as I did not set anything in the
>>> mysql database. This raises my first concern, how reliable this
>>> solution is? If I understand correctly, it is only depend on the
>>> audit mechanisms of the underlying DB?
>> No, it depends on the mechanisms of the backend-adapter (IStore) and
>> the configuration of the repository. The implementor of a
>> backend-adapter can decide to use a backend mechansim (if available),
>> implement an own mechanism or just don't offer auditing. The DBStore
>> for example supports auditing while the HibernateStore currently does
>> not. Since the DBStore is database (vendor) agnostic it implements
>> auditing support on its own.
>>
>> What exactly are your reliablility concerns?
>>
>>>
>>> Actually what I'm still missing regarding the "version control" is
>>> two small enhacements;
>>> - Possiblity to save "tagged" versions. (So anytime I want, I could
>>> create one, with some sort of a string comment.) Actualy if audit
>>> works well it seems to be quite an easy task to write a new UI
>>> extension, which allows to save timestamp informations with comments.
>> Yes, this would make a nice little feature request ;-)
>> In fact it would be comparingly easy to associate a point in time
>> with a name and optional comment.
>>
>>> - Some sort of rollback method in an audit could be useful
>>> (overwriting the current version, with the version in the audit). At
>>> this moment I can by-pass it by exporting the audit's information
>>> into an xml, and load it back into a transaction.
>> Although this has occasionally been requested I was always reluctant
>> to the idea of adding a mechanism that partially rolls back the
>> object graph of the repository (without going through a normal
>> transaction). Usually single objects in such an object graph can't be
>> seen in isolation and, as a consequence, not modified in isolation. I
>> think your approach of using an audit view in combination with a
>> transaction is the best you can do. You'd even not need an
>> intermediary XML file. Just detach objects from the audit view and
>> attach them to the transaction before committing it.
>>
>> Cheers
>> /Eike
>>
>>>
>>> Cheers,
>>> András
>>>
>>> Eike Stepper írta:
>>>> András Ökrös schrieb:
>>>>> Hi group,
>>>>>
>>>>> We have been testing the CDO for a while now, and it seems to be a
>>>>> promising technology.
>>>> Thank you ;-)
>>>>
>>>>>
>>>>> However we found one missing feature, which could be useful during
>>>>> modeling; some kind of version handling mechanism. In plain EMF it
>>>>> is not that important, as the instance files can be put into
>>>>> cvs/svn etc.. However with CDO we don't see any simple method like
>>>>> that.
>>>>>
>>>>> Is there any ongoing work about this? Or some solution, which we
>>>>> overlooked?
>>>> I think, yes, depending on what you understand of "some kind of
>>>> version handling mechanism" ;-)
>>>> CDO has always had and still has what we call "auditing" views.
>>>> A CDOAudit is a special type of CDOView with a configurable
>>>> timeStamp that judges what you're seeing in the view. Or better
>>>> "when".
>>>> Auditing must be supported by the used store and enabled by the
>>>> repository.
>>>> Then clients can simply call session.openAudit(timeStamp) to see an
>>>> old state of the object graph.
>>>> I've just added the CDOAudit.setTimeStamp() method, so you might
>>>> want to try the latest sources.
>>>>
>>>> I would appreciate when you evaluate this feature and tell me if it
>>>> suits your needs.
>>>>
>>>> Cheers
>>>> /Eike


Previous Topic:CDO resourceSet
Next Topic:How can i poof an elis datat?
Goto Forum:
  


Current Time: Wed Jan 22 17:04:10 GMT 2020

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

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

Back to the top