Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] Historical states
[CDO] Historical states [message #425399] Mon, 24 November 2008 22:10 Go to next message
Anders Forsell is currently offline Anders ForsellFriend
Messages: 127
Registered: July 2009
Senior Member
Hi,

After listening to Eike's excellent presentation of CDO at ESE I have some
followup questions:

- How is the Ecore model mapped to tables and references in a relational
database? For example, is it easy to look at the database and understand how
to query for model elements in a SQL query? Would an OO database make the
mapping cleaner and more efficient?
- I understand that you can look at historical states (audit views) from the
repository. Is a new historical state generated for each committed
transaction? Any need for purging to reduce database size?
- What is the tradeoff between committing transactions often (in small
chunks) vs. committing many changes in one large transaction?
- Can non-conflicting changes within an EObject (for example changing two
different attributes) by two different clients be merged automatically?

Thanks,

---
Anders
Re: [CDO] Historical states [message #425400 is a reply to message #425399] Mon, 24 November 2008 23:00 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6487
Registered: July 2009
Senior Member
Anders,

Comments below...



Anders Forsell schrieb:
> Hi,
>
> After listening to Eike's excellent presentation of CDO at ESE
Thank you!

> I have some followup questions:
>
> - How is the Ecore model mapped to tables and references in a
> relational database? For example, is it easy to look at the database
> and understand how to query for model elements in a SQL query?
CDO offers two different integration with relational database back-ends:

1) The default DBStore, which is a proprietary O/R mapper with
configurable and pluggable mapping strategies.
2) A HibernateStore, which internally uses the Teneo runtime support for
Hibernate and/or the Teneo mapping generator.

If you don't care too much about the influence on the actual mappings
the DBStore could be a good choice because it is comparingly easy to
install and maintain (no additional dependencies). Please note, that the
DBStore currently does *only* support auditing mode!

On the other hand Hibernate is a widly accepted framework for O/R
mapping and we don't intend to compete with Hibernate in this regard. I
think you can find informations on the Teneo web site about the mapping
generation. Please note that the HibernateStore currently does *not*
support auditing mode.

Would you like to know more about the actual mappings generated by the
DBStore?

> Would an OO database make the mapping cleaner and more efficient?
OO database do not *map* objects to something different. So I'd say,
they are cleaner and, thu, more efficient ;-)

Simon might want to come up with some measures...

> - I understand that you can look at historical states (audit views)
> from the repository. Is a new historical state generated for each
> committed transaction?
This depends on the back-end type and the chosen integration (store).
Since the DBStore is currently the only persistent store I guess you
mean it ;-)
So yes, per committed transaction a new revision per new/modified object
is written to the database.


> Any need for purging to reduce database size?
We already discussed this issue and possible solutions in the team.
Would you mind to file an enhancement request to make the discussion
more transparent?

> - What is the tradeoff between committing transactions often (in small
> chunks) vs. committing many changes in one large transaction?
This can make indeed a big difference! Both approaches have their
advantages and drawbacks:

committing transactions often (in small chunks) --> fewer
OutOfMemroyExceptions, database can even grow exponential

committing many changes in one large transaction --> local memory could
be (over-) stressed, database increase more adequately reflects actual
change


> - Can non-conflicting changes within an EObject (for example changing
> two different attributes) by two different clients be merged
> automatically?
If I understood the question right, then no. After a client successfully
committed a transaction the repository notifies the other clients about
the changed objects. By default the repository does not distribute the
changed values, just the IDs of the objects. These objects are
"invalidated" in the other clients, that means set to state PROXY if
they were CLEAN and set to state CONFLICT if they were DIRTY.

I find the idea interesting to automatically and locally merge
non-conflicting remote changes. Although I also foresee some problems
with lazy-ness I'd appreciate if you file a bugzilla.

Cheers
/Eike

----
http://thegordian.blogspot.com


Re: [CDO] Historical states [message #425401 is a reply to message #425400] Mon, 24 November 2008 23:13 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
Anders,


Eike Stepper wrote:
> Anders,
>
> Comments below...
>
>
>
> Anders Forsell schrieb:
>> Hi,
>>
>> After listening to Eike's excellent presentation of CDO at ESE
> Thank you!
>
>> I have some followup questions:
>>
>> - How is the Ecore model mapped to tables and references in a
>> relational database? For example, is it easy to look at the database
>> and understand how to query for model elements in a SQL query?
> CDO offers two different integration with relational database back-ends:
>
> 1) The default DBStore, which is a proprietary O/R mapper with
> configurable and pluggable mapping strategies.
> 2) A HibernateStore, which internally uses the Teneo runtime support for
> Hibernate and/or the Teneo mapping generator.
>
> If you don't care too much about the influence on the actual mappings
> the DBStore could be a good choice because it is comparingly easy to
> install and maintain (no additional dependencies). Please note, that the
> DBStore currently does *only* support auditing mode!
>
> On the other hand Hibernate is a widly accepted framework for O/R
> mapping and we don't intend to compete with Hibernate in this regard. I
> think you can find informations on the Teneo web site about the mapping
> generation. Please note that the HibernateStore currently does *not*
> support auditing mode.
>
> Would you like to know more about the actual mappings generated by the
> DBStore?
>
>> Would an OO database make the mapping cleaner and more efficient?
> OO database do not *map* objects to something different. So I'd say,
> they are cleaner and, thu, more efficient ;-)
>
> Simon might want to come up with some measures...
Eike knows me very well!!
CDO will offer soon another integration with Objectivity Inc. It is a
Object database that is very fast.

So far our performance framework showed exactly what you just said...
more efficient. About the cleaner ... complicated code could be cleaner
than simple code... so I won't say anything about that if the code is
cleaner !! :-) You still have a mapping since you need to make sure that
the objectDatabase knows how to deal with EMF or CDO objects (Feature,
many relationship, etc..)!



>
>> - I understand that you can look at historical states (audit views)
>> from the repository. Is a new historical state generated for each
>> committed transaction?
> This depends on the back-end type and the chosen integration (store).
> Since the DBStore is currently the only persistent store I guess you
> mean it ;-)
> So yes, per committed transaction a new revision per new/modified object
> is written to the database.
>
>
>> Any need for purging to reduce database size?
> We already discussed this issue and possible solutions in the team.
> Would you mind to file an enhancement request to make the discussion
> more transparent?
>
>> - What is the tradeoff between committing transactions often (in small
>> chunks) vs. committing many changes in one large transaction?
> This can make indeed a big difference! Both approaches have their
> advantages and drawbacks:
>
> committing transactions often (in small chunks) --> fewer
> OutOfMemroyExceptions, database can even grow exponential
>
> committing many changes in one large transaction --> local memory could
> be (over-) stressed, database increase more adequately reflects actual
> change
It is faster to commit one big graph than many small one. The difference
could be very huge!! The last time I test that.. it was 10 times slower!

>
>
>> - Can non-conflicting changes within an EObject (for example changing
>> two different attributes) by two different clients be merged
>> automatically?
> If I understood the question right, then no. After a client successfully
> committed a transaction the repository notifies the other clients about
> the changed objects. By default the repository does not distribute the
> changed values, just the IDs of the objects. These objects are
> "invalidated" in the other clients, that means set to state PROXY if
> they were CLEAN and set to state CONFLICT if they were DIRTY.
>
> I find the idea interesting to automatically and locally merge
> non-conflicting remote changes. Although I also foresee some problems
> with lazy-ness I'd appreciate if you file a bugzilla.
>
I agree with Eike, this is very interesting question and could be easily
feasible for a cost.(to transfer deltas to that client).

> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
Re: [CDO] Historical states [message #425416 is a reply to message #425401] Tue, 25 November 2008 20:09 Go to previous message
Anders Forsell is currently offline Anders ForsellFriend
Messages: 127
Registered: July 2009
Senior Member
Thanks for your quick answers!

I have filed the following enhancement requests:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=256490
https://bugs.eclipse.org/bugs/show_bug.cgi?id=256492

---
Anders

"Simon McDuff" <smcduff@hotmail.com> skrev i meddelandet
news:ggfcaq$641$1@build.eclipse.org...
> Anders,
>
>
> Eike Stepper wrote:
>> Anders,
>>
>> Comments below...
>>
>>
>>
>> Anders Forsell schrieb:
>>> Hi,
>>>
>>> After listening to Eike's excellent presentation of CDO at ESE
>> Thank you!
>>
>>> I have some followup questions:
>>>
>>> - How is the Ecore model mapped to tables and references in a relational
>>> database? For example, is it easy to look at the database and understand
>>> how to query for model elements in a SQL query?
>> CDO offers two different integration with relational database back-ends:
>>
>> 1) The default DBStore, which is a proprietary O/R mapper with
>> configurable and pluggable mapping strategies.
>> 2) A HibernateStore, which internally uses the Teneo runtime support for
>> Hibernate and/or the Teneo mapping generator.
>>
>> If you don't care too much about the influence on the actual mappings the
>> DBStore could be a good choice because it is comparingly easy to install
>> and maintain (no additional dependencies). Please note, that the DBStore
>> currently does *only* support auditing mode!
>>
>> On the other hand Hibernate is a widly accepted framework for O/R mapping
>> and we don't intend to compete with Hibernate in this regard. I think you
>> can find informations on the Teneo web site about the mapping generation.
>> Please note that the HibernateStore currently does *not* support auditing
>> mode.
>>
>> Would you like to know more about the actual mappings generated by the
>> DBStore?
>>
>>> Would an OO database make the mapping cleaner and more efficient?
>> OO database do not *map* objects to something different. So I'd say, they
>> are cleaner and, thu, more efficient ;-)
>>
>> Simon might want to come up with some measures...
> Eike knows me very well!!
> CDO will offer soon another integration with Objectivity Inc. It is a
> Object database that is very fast.
>
> So far our performance framework showed exactly what you just said... more
> efficient. About the cleaner ... complicated code could be cleaner than
> simple code... so I won't say anything about that if the code is cleaner
> !! :-) You still have a mapping since you need to make sure that the
> objectDatabase knows how to deal with EMF or CDO objects (Feature, many
> relationship, etc..)!
>
>
>
>>
>>> - I understand that you can look at historical states (audit views) from
>>> the repository. Is a new historical state generated for each committed
>>> transaction?
>> This depends on the back-end type and the chosen integration (store).
>> Since the DBStore is currently the only persistent store I guess you mean
>> it ;-)
>> So yes, per committed transaction a new revision per new/modified object
>> is written to the database.
>>
>>
>>> Any need for purging to reduce database size?
>> We already discussed this issue and possible solutions in the team. Would
>> you mind to file an enhancement request to make the discussion more
>> transparent?
>>
>>> - What is the tradeoff between committing transactions often (in small
>>> chunks) vs. committing many changes in one large transaction?
>> This can make indeed a big difference! Both approaches have their
>> advantages and drawbacks:
>>
>> committing transactions often (in small chunks) --> fewer
>> OutOfMemroyExceptions, database can even grow exponential
>>
>> committing many changes in one large transaction --> local memory could
>> be (over-) stressed, database increase more adequately reflects actual
>> change
> It is faster to commit one big graph than many small one. The difference
> could be very huge!! The last time I test that.. it was 10 times slower!
>
>>
>>
>>> - Can non-conflicting changes within an EObject (for example changing
>>> two different attributes) by two different clients be merged
>>> automatically?
>> If I understood the question right, then no. After a client successfully
>> committed a transaction the repository notifies the other clients about
>> the changed objects. By default the repository does not distribute the
>> changed values, just the IDs of the objects. These objects are
>> "invalidated" in the other clients, that means set to state PROXY if they
>> were CLEAN and set to state CONFLICT if they were DIRTY.
>>
>> I find the idea interesting to automatically and locally merge
>> non-conflicting remote changes. Although I also foresee some problems
>> with lazy-ness I'd appreciate if you file a bugzilla.
>>
> I agree with Eike, this is very interesting question and could be easily
> feasible for a cost.(to transfer deltas to that client).
>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
Previous Topic:[Teneo] Trying to use the timestamp in a legacy database as the optimistic locking column
Next Topic:[New Article] How Scalable are my Models?
Goto Forum:
  


Current Time: Sun Apr 05 00:05:29 GMT 2020

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

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

Back to the top