Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » Teneo / Hibernate / Compare
| Teneo / Hibernate / Compare [message #96975] |
Sun, 23 September 2007 10:15  |
Eclipse User |
|
|
|
Originally posted by: andrew_steady.hotmail.com
Hi,
We are considering using Teneo to solve a problem which I describe below.
I wondered if anyone could give insight into whether Teneo is a good fit
for us given the following:
1. We are required to use java 1.4 and Eclipse 3.2. Will teneo on going
support this platform?
2. Is it possible to get hold of the delta between our "Detached" objects
and a DB we want to update, rather than just saving the detached objects?
If not is anyone aware of any OR/Rel mapping tools that will give a delta
instead of actually applying the change?
3. How stable is Teneo - is it recommend to use yet for live projects?
4. Our primary editing domain is XML. We only need a DB link for a save
after detached edits (and also initial conversion from DB to XML). Given
this I do not see that we require DB "EMF resources" and I don't think the
generation / UI tools give us much extra as we already have our primary,
offline XML-EMF solution. So what would Teneo offer us over simply using
Hibernate and mapping to our EMF objects (constructors made public) and
datatype conversion configured in Hibernate (if that would even work?).
If the answer to (2) is no - could EMF Compare compare the two sets of
instance data (one read in from DB) and one in EMF-XML and produce the
delta as EMF objects which could then be persisted to file and saved to
the DB (or another DB in the same state) by saving them as "detached"
hibernate objects?
Thanks in advance for any insights!
Andy
|
|
|
| Re: Teneo / Hibernate / Compare [message #96977 is a reply to message #96975] |
Sun, 23 September 2007 12:06  |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Andy,
My thoughts on this below. I'm sure others will want to elaborate...
Andrew Steady wrote:
> Hi,
>
> We are considering using Teneo to solve a problem which I describe
> below. I wondered if anyone could give insight into whether Teneo is a
> good fit for us given the following:
>
> 1. We are required to use java 1.4 and Eclipse 3.2. Will teneo on
> going support this platform?
The older 0.7.5 builds depend on older versions of Eclipse. (Just look
carefully at the dependencies on the download package.) Obviously
you'll get better support on the more recent streams rather than the
older ones.
>
> 2. Is it possible to get hold of the delta between our "Detached"
> objects and a DB we want to update, rather than just saving the
> detached objects?
> If not is anyone aware of any OR/Rel mapping tools that will give a
> delta instead of actually applying the change?
For a purpose such as this, you might want to use a ChangeRecorder to
build a Change model instance. It's basically an adapter that listens
to all changes and records them in a form that can be applied to undo
and redo all those changes. (I'd described how to do that on the EMF
newsgroup a few times, so a newsgroup-specific search should turn that up.)
>
> 3. How stable is Teneo - is it recommend to use yet for live projects?
Teneo is awesome. Many folks are using it and Martin is very responsive
to fixing problems.
>
> 4. Our primary editing domain is XML. We only need a DB link for a
> save after detached edits (and also initial conversion from DB to
> XML). Given this I do not see that we require DB "EMF resources" and I
> don't think the generation / UI tools give us much extra as we already
> have our primary, offline XML-EMF solution. So what would Teneo offer
> us over simply using Hibernate and mapping to our EMF objects
> (constructors made public) and datatype conversion configured in
> Hibernate (if that would even work?).
Teneo is very simple to use. With maybe a dozen lines of code added to
your existing editor everything will just work. Martin's always solved
many hard problems so there would be little point in duplicating that
effort.
>
>
> If the answer to (2) is no - could EMF Compare compare the two sets of
> instance data (one read in from DB) and one in EMF-XML and produce the
> delta as EMF objects which could then be persisted to file and saved
> to the DB (or another DB in the same state) by saving them as
> "detached" hibernate objects?
I think it could, but the change recorder approach seems more direct.
I.e., listen and record all the changes rather than try to figure them
out after the fact. (The matching problem is quite a hard one in general.)
>
> Thanks in advance for any insights!
>
> Andy
>
|
|
|
| Re: Teneo / Hibernate / Compare [message #97057 is a reply to message #96977] |
Sun, 23 September 2007 12:27 |
| Eclipse User |
|
|
|
Originally posted by: andrew_steady.hotmail.com
Hi Ed,
Thanks for response... lots to consider, but immediately I wanted to
clarify our detached mode of working. We can't collate changes in the
detached mode as you suggest because the DB may change in between. For
that reason we need to create a delta between whats in memory/xml and
whats in the DB.
I haven't heard of any OR/Rel mapping tool giving the delta instead of
making the updates so I figure we need to do the comparison in memory
ourselves so we can make the delta portable and show the user the
differences.
Doesn't seem like EMF compare gives you the differences between two sets
of instances so we may need to write that logic ourselves - shouldn't be
too taxing.
As for Teneo, sounds good then - if the versions will be compatible for
1.4/3.2 (I'll investigate further), we'll give it a go...
Thanks for your time as always,
Andy
|
|
|
| Re: Teneo / Hibernate / Compare [message #97071 is a reply to message #97057] |
Sun, 23 September 2007 12:35 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Andy,
I think EMF compare should be able to do exactly what you describe. If
the database can change out from under you while editing you could
obviously end up with an incoherent set of changes, so doing a careful
merge will be especially important. The general differencing problem is
a very hard one, so it's really best to reuse what's provided and help
improve it if there are any shortcomings...
Andrew Steady wrote:
> Hi Ed,
>
> Thanks for response... lots to consider, but immediately I wanted to
> clarify our detached mode of working. We can't collate changes in the
> detached mode as you suggest because the DB may change in between. For
> that reason we need to create a delta between whats in memory/xml and
> whats in the DB.
>
> I haven't heard of any OR/Rel mapping tool giving the delta instead of
> making the updates so I figure we need to do the comparison in memory
> ourselves so we can make the delta portable and show the user the
> differences.
>
> Doesn't seem like EMF compare gives you the differences between two
> sets of instances so we may need to write that logic ourselves -
> shouldn't be too taxing.
>
> As for Teneo, sounds good then - if the versions will be compatible
> for 1.4/3.2 (I'll investigate further), we'll give it a go...
>
> Thanks for your time as always,
>
> Andy
>
|
|
|
| Re: Teneo / Hibernate / Compare [message #97109 is a reply to message #97071] |
Mon, 24 September 2007 04:37 |
 Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Andy,
Ed has answered already most of your questions. For your question regarding live projects. I have
used Teneo over the past 2 years in one of my main projects I am working on (a 1000+ user business
app for a large building company) and it has worked without problems for me.
Just as Ed says new developments take place in the 0.8.0 branch but I will continue to solve
blocking issues in the 0.7.5 branch.
Regarding your 4th question. Teneo offers automatic mapping of your domain model to hibernate. In
addition it integrates EMF at runtime with Hibernate. The mapping logic can be influenced with
annotations. You can also initially create a mapping through Teneo and then for the rest maintain it
by hand.
The runtime integration is for supporting EMF lists (bidirectional/containment etc.) and specific
emf types (enums, anytype, datetype). In addition Teneo supports EMF FeatureMaps which is important
as more advanced xml schema constructs (multi-occ choice for example) are solved with a featuremap.
As a tip assuming that you would want to update the db with your detached instances. Hibernate needs
to know if an instance is already present in the db or not (otherwise updating results in creation
of new instances in the db).
It does this by checking the id or version property of an instance. In case of detached instances
the id and version property have to be explicitly modeled. If this is a blocking issue (i.e. you
don't control the model) there are probably workarounds to be found (as Hibernate is very
extendable) but adding id/version as a model element is the preferred/easiest way.
gr. Martin
Ed Merks wrote:
> Andy,
>
> I think EMF compare should be able to do exactly what you describe. If
> the database can change out from under you while editing you could
> obviously end up with an incoherent set of changes, so doing a careful
> merge will be especially important. The general differencing problem is
> a very hard one, so it's really best to reuse what's provided and help
> improve it if there are any shortcomings...
>
>
> Andrew Steady wrote:
>> Hi Ed,
>>
>> Thanks for response... lots to consider, but immediately I wanted to
>> clarify our detached mode of working. We can't collate changes in the
>> detached mode as you suggest because the DB may change in between. For
>> that reason we need to create a delta between whats in memory/xml and
>> whats in the DB.
>>
>> I haven't heard of any OR/Rel mapping tool giving the delta instead of
>> making the updates so I figure we need to do the comparison in memory
>> ourselves so we can make the delta portable and show the user the
>> differences.
>>
>> Doesn't seem like EMF compare gives you the differences between two
>> sets of instances so we may need to write that logic ourselves -
>> shouldn't be too taxing.
>>
>> As for Teneo, sounds good then - if the versions will be compatible
>> for 1.4/3.2 (I'll investigate further), we'll give it a go...
>>
>> Thanks for your time as always,
>>
>> Andy
>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: Teneo / Hibernate / Compare [message #97277 is a reply to message #97109] |
Tue, 25 September 2007 08:04 |
| Eclipse User |
|
|
|
Originally posted by: andrew_steady.hotmail.com
Hi Martin,
We will maintain the primary key in our XML editing mode, and for new
objects we be given a key before saving. Thus when we save our detached
objects vanilla Hibernate can tell whether to update or insert easily - I
tested this.
Our DB schema is pre-existing and we cannot change it, so we need to map
the EMF objects to that rather than (auto)generate a new schema.
So I don't see that we would benefit from the automatic mapping and
run-time integration teneo offers.
To summise we just want to be able to create new EMF instances with data
from the DB and then edit them locally persisting in XML, and on a
specific request save those detached instances (containing the primary
keys), all to our existing schema.
Is there any reason why we couldn't map hibernate directly to our EMF
objects without Teneo? I'm trying to understand what support we would get
from Teneo given our requirements.
Thanks for your time,
Andy
Martin Taal wrote:
> Hi Andy,
> Ed has answered already most of your questions. For your question regarding
live projects. I have
> used Teneo over the past 2 years in one of my main projects I am working on
(a 1000+ user business
> app for a large building company) and it has worked without problems for me.
> Just as Ed says new developments take place in the 0.8.0 branch but I will
continue to solve
> blocking issues in the 0.7.5 branch.
> Regarding your 4th question. Teneo offers automatic mapping of your domain
model to hibernate. In
> addition it integrates EMF at runtime with Hibernate. The mapping logic can
be influenced with
> annotations. You can also initially create a mapping through Teneo and then
for the rest maintain it
> by hand.
> The runtime integration is for supporting EMF lists
(bidirectional/containment etc.) and specific
> emf types (enums, anytype, datetype). In addition Teneo supports EMF
FeatureMaps which is important
> as more advanced xml schema constructs (multi-occ choice for example) are
solved with a featuremap.
> As a tip assuming that you would want to update the db with your detached
instances. Hibernate needs
> to know if an instance is already present in the db or not (otherwise
updating results in creation
> of new instances in the db).
> It does this by checking the id or version property of an instance. In case
of detached instances
> the id and version property have to be explicitly modeled. If this is a
blocking issue (i.e. you
> don't control the model) there are probably workarounds to be found (as
Hibernate is very
> extendable) but adding id/version as a model element is the
preferred/easiest way.
> gr. Martin
> Ed Merks wrote:
>> Andy,
>>
>> I think EMF compare should be able to do exactly what you describe. If
>> the database can change out from under you while editing you could
>> obviously end up with an incoherent set of changes, so doing a careful
>> merge will be especially important. The general differencing problem is
>> a very hard one, so it's really best to reuse what's provided and help
>> improve it if there are any shortcomings...
>>
>>
>> Andrew Steady wrote:
>>> Hi Ed,
>>>
>>> Thanks for response... lots to consider, but immediately I wanted to
>>> clarify our detached mode of working. We can't collate changes in the
>>> detached mode as you suggest because the DB may change in between. For
>>> that reason we need to create a delta between whats in memory/xml and
>>> whats in the DB.
>>>
>>> I haven't heard of any OR/Rel mapping tool giving the delta instead of
>>> making the updates so I figure we need to do the comparison in memory
>>> ourselves so we can make the delta portable and show the user the
>>> differences.
>>>
>>> Doesn't seem like EMF compare gives you the differences between two
>>> sets of instances so we may need to write that logic ourselves -
>>> shouldn't be too taxing.
>>>
>>> As for Teneo, sounds good then - if the versions will be compatible
>>> for 1.4/3.2 (I'll investigate further), we'll give it a go...
>>>
>>> Thanks for your time as always,
>>>
>>> Andy
>>>
|
|
|
| Re: Teneo / Hibernate / Compare [message #97292 is a reply to message #97277] |
Tue, 25 September 2007 09:07 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Andy,
It all depends on how much the db schema differs from the automatic mapping. Teneo will generate a
hbm file (in memory but you easily get to it) so it can help you to get started from there. The
mapping will contain column/table names etc so then it is only to change those (assuming that the
structure of the db is similar).
Teneo runtime (which can use a manually created mapping file) offers support for the emf featuremap,
anytype and EMF list implementations (bi-directional/containment). It is possible that in your case
bi-directional/containment lists do not apply. In that case there is less need for Teneo runtime. I
would test this out without Teneo and see how far you get.
gr. Martin
Andrew Steady wrote:
> Hi Martin,
>
> We will maintain the primary key in our XML editing mode, and for new
> objects we be given a key before saving. Thus when we save our detached
> objects vanilla Hibernate can tell whether to update or insert easily -
> I tested this.
> Our DB schema is pre-existing and we cannot change it, so we need to map
> the EMF objects to that rather than (auto)generate a new schema.
>
> So I don't see that we would benefit from the automatic mapping and
> run-time integration teneo offers.
> To summise we just want to be able to create new EMF instances with data
> from the DB and then edit them locally persisting in XML, and on a
> specific request save those detached instances (containing the primary
> keys), all to our existing schema.
>
> Is there any reason why we couldn't map hibernate directly to our EMF
> objects without Teneo? I'm trying to understand what support we would
> get from Teneo given our requirements.
>
> Thanks for your time,
>
> Andy
>
>
>
>
>
> Martin Taal wrote:
>
>> Hi Andy,
>> Ed has answered already most of your questions. For your question
>> regarding
> live projects. I have
>> used Teneo over the past 2 years in one of my main projects I am
>> working on
> (a 1000+ user business
>> app for a large building company) and it has worked without problems
>> for me.
>
>> Just as Ed says new developments take place in the 0.8.0 branch but I
>> will
> continue to solve
>> blocking issues in the 0.7.5 branch.
>
>> Regarding your 4th question. Teneo offers automatic mapping of your
>> domain
> model to hibernate. In
>> addition it integrates EMF at runtime with Hibernate. The mapping
>> logic can
> be influenced with
>> annotations. You can also initially create a mapping through Teneo and
>> then
> for the rest maintain it
>> by hand.
>> The runtime integration is for supporting EMF lists
> (bidirectional/containment etc.) and specific
>> emf types (enums, anytype, datetype). In addition Teneo supports EMF
> FeatureMaps which is important
>> as more advanced xml schema constructs (multi-occ choice for example) are
> solved with a featuremap.
>
>> As a tip assuming that you would want to update the db with your detached
> instances. Hibernate needs
>> to know if an instance is already present in the db or not (otherwise
> updating results in creation
>> of new instances in the db).
>> It does this by checking the id or version property of an instance. In
>> case
> of detached instances
>> the id and version property have to be explicitly modeled. If this is a
> blocking issue (i.e. you
>> don't control the model) there are probably workarounds to be found (as
> Hibernate is very
>> extendable) but adding id/version as a model element is the
> preferred/easiest way.
>
>> gr. Martin
>
>> Ed Merks wrote:
>>> Andy,
>>>
>>> I think EMF compare should be able to do exactly what you describe.
>>> If the database can change out from under you while editing you could
>>> obviously end up with an incoherent set of changes, so doing a
>>> careful merge will be especially important. The general differencing
>>> problem is a very hard one, so it's really best to reuse what's
>>> provided and help improve it if there are any shortcomings...
>>>
>>>
>>> Andrew Steady wrote:
>>>> Hi Ed,
>>>>
>>>> Thanks for response... lots to consider, but immediately I wanted to
>>>> clarify our detached mode of working. We can't collate changes in
>>>> the detached mode as you suggest because the DB may change in
>>>> between. For that reason we need to create a delta between whats in
>>>> memory/xml and whats in the DB.
>>>>
>>>> I haven't heard of any OR/Rel mapping tool giving the delta instead
>>>> of making the updates so I figure we need to do the comparison in
>>>> memory ourselves so we can make the delta portable and show the user
>>>> the differences.
>>>>
>>>> Doesn't seem like EMF compare gives you the differences between two
>>>> sets of instances so we may need to write that logic ourselves -
>>>> shouldn't be too taxing.
>>>>
>>>> As for Teneo, sounds good then - if the versions will be compatible
>>>> for 1.4/3.2 (I'll investigate further), we'll give it a go...
>>>>
>>>> Thanks for your time as always,
>>>>
>>>> Andy
>>>>
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: Teneo / Hibernate / Compare [message #97478 is a reply to message #97292] |
Wed, 26 September 2007 02:14 |
| Eclipse User |
|
|
|
Originally posted by: andrew_steady.hotmail.com
Hi Martin,
We use containment relationships and Elists extensively. However I think
the fact that we do not need any run time functionality/integration (just
bulk conversions) between EMF and the DB means we can map directly to our
EMF classes. I have now tried this out and it works directly for
everything except lists, where I've had to add a dummy property and
setters/getters so that the getters can return a Set rather than a EList.
We'll find out if this approach will run into more problems as our OR
mappings get more complex.
Thanks for you advice,
Andy
Martin Taal wrote:
> Hi Andy,
> It all depends on how much the db schema differs from the automatic mapping.
Teneo will generate a
> hbm file (in memory but you easily get to it) so it can help you to get
started from there. The
> mapping will contain column/table names etc so then it is only to change
those (assuming that the
> structure of the db is similar).
> Teneo runtime (which can use a manually created mapping file) offers support
for the emf featuremap,
> anytype and EMF list implementations (bi-directional/containment). It is
possible that in your case
> bi-directional/containment lists do not apply. In that case there is less
need for Teneo runtime. I
> would test this out without Teneo and see how far you get.
> gr. Martin
> Andrew Steady wrote:
>> Hi Martin,
>>
>> We will maintain the primary key in our XML editing mode, and for new
>> objects we be given a key before saving. Thus when we save our detached
>> objects vanilla Hibernate can tell whether to update or insert easily -
>> I tested this.
>> Our DB schema is pre-existing and we cannot change it, so we need to map
>> the EMF objects to that rather than (auto)generate a new schema.
>>
>> So I don't see that we would benefit from the automatic mapping and
>> run-time integration teneo offers.
>> To summise we just want to be able to create new EMF instances with data
>> from the DB and then edit them locally persisting in XML, and on a
>> specific request save those detached instances (containing the primary
>> keys), all to our existing schema.
>>
>> Is there any reason why we couldn't map hibernate directly to our EMF
>> objects without Teneo? I'm trying to understand what support we would
>> get from Teneo given our requirements.
>>
>> Thanks for your time,
>>
>> Andy
>>
>>
>>
>>
>>
>> Martin Taal wrote:
>>
>>> Hi Andy,
>>> Ed has answered already most of your questions. For your question
>>> regarding
>> live projects. I have
>>> used Teneo over the past 2 years in one of my main projects I am
>>> working on
>> (a 1000+ user business
>>> app for a large building company) and it has worked without problems
>>> for me.
>>
>>> Just as Ed says new developments take place in the 0.8.0 branch but I
>>> will
>> continue to solve
>>> blocking issues in the 0.7.5 branch.
>>
>>> Regarding your 4th question. Teneo offers automatic mapping of your
>>> domain
>> model to hibernate. In
>>> addition it integrates EMF at runtime with Hibernate. The mapping
>>> logic can
>> be influenced with
>>> annotations. You can also initially create a mapping through Teneo and
>>> then
>> for the rest maintain it
>>> by hand.
>>> The runtime integration is for supporting EMF lists
>> (bidirectional/containment etc.) and specific
>>> emf types (enums, anytype, datetype). In addition Teneo supports EMF
>> FeatureMaps which is important
>>> as more advanced xml schema constructs (multi-occ choice for example) are
>> solved with a featuremap.
>>
>>> As a tip assuming that you would want to update the db with your detached
>> instances. Hibernate needs
>>> to know if an instance is already present in the db or not (otherwise
>> updating results in creation
>>> of new instances in the db).
>>> It does this by checking the id or version property of an instance. In
>>> case
>> of detached instances
>>> the id and version property have to be explicitly modeled. If this is a
>> blocking issue (i.e. you
>>> don't control the model) there are probably workarounds to be found (as
>> Hibernate is very
>>> extendable) but adding id/version as a model element is the
>> preferred/easiest way.
>>
>>> gr. Martin
>>
>>> Ed Merks wrote:
>>>> Andy,
>>>>
>>>> I think EMF compare should be able to do exactly what you describe.
>>>> If the database can change out from under you while editing you could
>>>> obviously end up with an incoherent set of changes, so doing a
>>>> careful merge will be especially important. The general differencing
>>>> problem is a very hard one, so it's really best to reuse what's
>>>> provided and help improve it if there are any shortcomings...
>>>>
>>>>
>>>> Andrew Steady wrote:
>>>>> Hi Ed,
>>>>>
>>>>> Thanks for response... lots to consider, but immediately I wanted to
>>>>> clarify our detached mode of working. We can't collate changes in
>>>>> the detached mode as you suggest because the DB may change in
>>>>> between. For that reason we need to create a delta between whats in
>>>>> memory/xml and whats in the DB.
>>>>>
>>>>> I haven't heard of any OR/Rel mapping tool giving the delta instead
>>>>> of making the updates so I figure we need to do the comparison in
>>>>> memory ourselves so we can make the delta portable and show the user
>>>>> the differences.
>>>>>
>>>>> Doesn't seem like EMF compare gives you the differences between two
>>>>> sets of instances so we may need to write that logic ourselves -
>>>>> shouldn't be too taxing.
>>>>>
>>>>> As for Teneo, sounds good then - if the versions will be compatible
>>>>> for 1.4/3.2 (I'll investigate further), we'll give it a go...
>>>>>
>>>>> Thanks for your time as always,
>>>>>
>>>>> Andy
>>>>>
>>
|
|
|
| Re: Teneo / Hibernate / Compare [message #609772 is a reply to message #96975] |
Sun, 23 September 2007 12:06 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Andy,
My thoughts on this below. I'm sure others will want to elaborate...
Andrew Steady wrote:
> Hi,
>
> We are considering using Teneo to solve a problem which I describe
> below. I wondered if anyone could give insight into whether Teneo is a
> good fit for us given the following:
>
> 1. We are required to use java 1.4 and Eclipse 3.2. Will teneo on
> going support this platform?
The older 0.7.5 builds depend on older versions of Eclipse. (Just look
carefully at the dependencies on the download package.) Obviously
you'll get better support on the more recent streams rather than the
older ones.
>
> 2. Is it possible to get hold of the delta between our "Detached"
> objects and a DB we want to update, rather than just saving the
> detached objects?
> If not is anyone aware of any OR/Rel mapping tools that will give a
> delta instead of actually applying the change?
For a purpose such as this, you might want to use a ChangeRecorder to
build a Change model instance. It's basically an adapter that listens
to all changes and records them in a form that can be applied to undo
and redo all those changes. (I'd described how to do that on the EMF
newsgroup a few times, so a newsgroup-specific search should turn that up.)
>
> 3. How stable is Teneo - is it recommend to use yet for live projects?
Teneo is awesome. Many folks are using it and Martin is very responsive
to fixing problems.
>
> 4. Our primary editing domain is XML. We only need a DB link for a
> save after detached edits (and also initial conversion from DB to
> XML). Given this I do not see that we require DB "EMF resources" and I
> don't think the generation / UI tools give us much extra as we already
> have our primary, offline XML-EMF solution. So what would Teneo offer
> us over simply using Hibernate and mapping to our EMF objects
> (constructors made public) and datatype conversion configured in
> Hibernate (if that would even work?).
Teneo is very simple to use. With maybe a dozen lines of code added to
your existing editor everything will just work. Martin's always solved
many hard problems so there would be little point in duplicating that
effort.
>
>
> If the answer to (2) is no - could EMF Compare compare the two sets of
> instance data (one read in from DB) and one in EMF-XML and produce the
> delta as EMF objects which could then be persisted to file and saved
> to the DB (or another DB in the same state) by saving them as
> "detached" hibernate objects?
I think it could, but the change recorder approach seems more direct.
I.e., listen and record all the changes rather than try to figure them
out after the fact. (The matching problem is quite a hard one in general.)
>
> Thanks in advance for any insights!
>
> Andy
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Teneo / Hibernate / Compare [message #609775 is a reply to message #96977] |
Sun, 23 September 2007 12:27 |
| Eclipse User |
|
|
|
Originally posted by: andrew_steady.hotmail.com
Hi Ed,
Thanks for response... lots to consider, but immediately I wanted to
clarify our detached mode of working. We can't collate changes in the
detached mode as you suggest because the DB may change in between. For
that reason we need to create a delta between whats in memory/xml and
whats in the DB.
I haven't heard of any OR/Rel mapping tool giving the delta instead of
making the updates so I figure we need to do the comparison in memory
ourselves so we can make the delta portable and show the user the
differences.
Doesn't seem like EMF compare gives you the differences between two sets
of instances so we may need to write that logic ourselves - shouldn't be
too taxing.
As for Teneo, sounds good then - if the versions will be compatible for
1.4/3.2 (I'll investigate further), we'll give it a go...
Thanks for your time as always,
Andy
|
|
|
| Re: Teneo / Hibernate / Compare [message #609777 is a reply to message #97057] |
Sun, 23 September 2007 12:35 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Andy,
I think EMF compare should be able to do exactly what you describe. If
the database can change out from under you while editing you could
obviously end up with an incoherent set of changes, so doing a careful
merge will be especially important. The general differencing problem is
a very hard one, so it's really best to reuse what's provided and help
improve it if there are any shortcomings...
Andrew Steady wrote:
> Hi Ed,
>
> Thanks for response... lots to consider, but immediately I wanted to
> clarify our detached mode of working. We can't collate changes in the
> detached mode as you suggest because the DB may change in between. For
> that reason we need to create a delta between whats in memory/xml and
> whats in the DB.
>
> I haven't heard of any OR/Rel mapping tool giving the delta instead of
> making the updates so I figure we need to do the comparison in memory
> ourselves so we can make the delta portable and show the user the
> differences.
>
> Doesn't seem like EMF compare gives you the differences between two
> sets of instances so we may need to write that logic ourselves -
> shouldn't be too taxing.
>
> As for Teneo, sounds good then - if the versions will be compatible
> for 1.4/3.2 (I'll investigate further), we'll give it a go...
>
> Thanks for your time as always,
>
> Andy
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Teneo / Hibernate / Compare [message #609785 is a reply to message #97071] |
Mon, 24 September 2007 04:37 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Andy,
Ed has answered already most of your questions. For your question regarding live projects. I have
used Teneo over the past 2 years in one of my main projects I am working on (a 1000+ user business
app for a large building company) and it has worked without problems for me.
Just as Ed says new developments take place in the 0.8.0 branch but I will continue to solve
blocking issues in the 0.7.5 branch.
Regarding your 4th question. Teneo offers automatic mapping of your domain model to hibernate. In
addition it integrates EMF at runtime with Hibernate. The mapping logic can be influenced with
annotations. You can also initially create a mapping through Teneo and then for the rest maintain it
by hand.
The runtime integration is for supporting EMF lists (bidirectional/containment etc.) and specific
emf types (enums, anytype, datetype). In addition Teneo supports EMF FeatureMaps which is important
as more advanced xml schema constructs (multi-occ choice for example) are solved with a featuremap.
As a tip assuming that you would want to update the db with your detached instances. Hibernate needs
to know if an instance is already present in the db or not (otherwise updating results in creation
of new instances in the db).
It does this by checking the id or version property of an instance. In case of detached instances
the id and version property have to be explicitly modeled. If this is a blocking issue (i.e. you
don't control the model) there are probably workarounds to be found (as Hibernate is very
extendable) but adding id/version as a model element is the preferred/easiest way.
gr. Martin
Ed Merks wrote:
> Andy,
>
> I think EMF compare should be able to do exactly what you describe. If
> the database can change out from under you while editing you could
> obviously end up with an incoherent set of changes, so doing a careful
> merge will be especially important. The general differencing problem is
> a very hard one, so it's really best to reuse what's provided and help
> improve it if there are any shortcomings...
>
>
> Andrew Steady wrote:
>> Hi Ed,
>>
>> Thanks for response... lots to consider, but immediately I wanted to
>> clarify our detached mode of working. We can't collate changes in the
>> detached mode as you suggest because the DB may change in between. For
>> that reason we need to create a delta between whats in memory/xml and
>> whats in the DB.
>>
>> I haven't heard of any OR/Rel mapping tool giving the delta instead of
>> making the updates so I figure we need to do the comparison in memory
>> ourselves so we can make the delta portable and show the user the
>> differences.
>>
>> Doesn't seem like EMF compare gives you the differences between two
>> sets of instances so we may need to write that logic ourselves -
>> shouldn't be too taxing.
>>
>> As for Teneo, sounds good then - if the versions will be compatible
>> for 1.4/3.2 (I'll investigate further), we'll give it a go...
>>
>> Thanks for your time as always,
>>
>> Andy
>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: Teneo / Hibernate / Compare [message #609802 is a reply to message #97109] |
Tue, 25 September 2007 08:04 |
| Eclipse User |
|
|
|
Originally posted by: andrew_steady.hotmail.com
Hi Martin,
We will maintain the primary key in our XML editing mode, and for new
objects we be given a key before saving. Thus when we save our detached
objects vanilla Hibernate can tell whether to update or insert easily - I
tested this.
Our DB schema is pre-existing and we cannot change it, so we need to map
the EMF objects to that rather than (auto)generate a new schema.
So I don't see that we would benefit from the automatic mapping and
run-time integration teneo offers.
To summise we just want to be able to create new EMF instances with data
from the DB and then edit them locally persisting in XML, and on a
specific request save those detached instances (containing the primary
keys), all to our existing schema.
Is there any reason why we couldn't map hibernate directly to our EMF
objects without Teneo? I'm trying to understand what support we would get
from Teneo given our requirements.
Thanks for your time,
Andy
Martin Taal wrote:
> Hi Andy,
> Ed has answered already most of your questions. For your question regarding
live projects. I have
> used Teneo over the past 2 years in one of my main projects I am working on
(a 1000+ user business
> app for a large building company) and it has worked without problems for me.
> Just as Ed says new developments take place in the 0.8.0 branch but I will
continue to solve
> blocking issues in the 0.7.5 branch.
> Regarding your 4th question. Teneo offers automatic mapping of your domain
model to hibernate. In
> addition it integrates EMF at runtime with Hibernate. The mapping logic can
be influenced with
> annotations. You can also initially create a mapping through Teneo and then
for the rest maintain it
> by hand.
> The runtime integration is for supporting EMF lists
(bidirectional/containment etc.) and specific
> emf types (enums, anytype, datetype). In addition Teneo supports EMF
FeatureMaps which is important
> as more advanced xml schema constructs (multi-occ choice for example) are
solved with a featuremap.
> As a tip assuming that you would want to update the db with your detached
instances. Hibernate needs
> to know if an instance is already present in the db or not (otherwise
updating results in creation
> of new instances in the db).
> It does this by checking the id or version property of an instance. In case
of detached instances
> the id and version property have to be explicitly modeled. If this is a
blocking issue (i.e. you
> don't control the model) there are probably workarounds to be found (as
Hibernate is very
> extendable) but adding id/version as a model element is the
preferred/easiest way.
> gr. Martin
> Ed Merks wrote:
>> Andy,
>>
>> I think EMF compare should be able to do exactly what you describe. If
>> the database can change out from under you while editing you could
>> obviously end up with an incoherent set of changes, so doing a careful
>> merge will be especially important. The general differencing problem is
>> a very hard one, so it's really best to reuse what's provided and help
>> improve it if there are any shortcomings...
>>
>>
>> Andrew Steady wrote:
>>> Hi Ed,
>>>
>>> Thanks for response... lots to consider, but immediately I wanted to
>>> clarify our detached mode of working. We can't collate changes in the
>>> detached mode as you suggest because the DB may change in between. For
>>> that reason we need to create a delta between whats in memory/xml and
>>> whats in the DB.
>>>
>>> I haven't heard of any OR/Rel mapping tool giving the delta instead of
>>> making the updates so I figure we need to do the comparison in memory
>>> ourselves so we can make the delta portable and show the user the
>>> differences.
>>>
>>> Doesn't seem like EMF compare gives you the differences between two
>>> sets of instances so we may need to write that logic ourselves -
>>> shouldn't be too taxing.
>>>
>>> As for Teneo, sounds good then - if the versions will be compatible
>>> for 1.4/3.2 (I'll investigate further), we'll give it a go...
>>>
>>> Thanks for your time as always,
>>>
>>> Andy
>>>
|
|
|
| Re: Teneo / Hibernate / Compare [message #609803 is a reply to message #97277] |
Tue, 25 September 2007 09:07 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Andy,
It all depends on how much the db schema differs from the automatic mapping. Teneo will generate a
hbm file (in memory but you easily get to it) so it can help you to get started from there. The
mapping will contain column/table names etc so then it is only to change those (assuming that the
structure of the db is similar).
Teneo runtime (which can use a manually created mapping file) offers support for the emf featuremap,
anytype and EMF list implementations (bi-directional/containment). It is possible that in your case
bi-directional/containment lists do not apply. In that case there is less need for Teneo runtime. I
would test this out without Teneo and see how far you get.
gr. Martin
Andrew Steady wrote:
> Hi Martin,
>
> We will maintain the primary key in our XML editing mode, and for new
> objects we be given a key before saving. Thus when we save our detached
> objects vanilla Hibernate can tell whether to update or insert easily -
> I tested this.
> Our DB schema is pre-existing and we cannot change it, so we need to map
> the EMF objects to that rather than (auto)generate a new schema.
>
> So I don't see that we would benefit from the automatic mapping and
> run-time integration teneo offers.
> To summise we just want to be able to create new EMF instances with data
> from the DB and then edit them locally persisting in XML, and on a
> specific request save those detached instances (containing the primary
> keys), all to our existing schema.
>
> Is there any reason why we couldn't map hibernate directly to our EMF
> objects without Teneo? I'm trying to understand what support we would
> get from Teneo given our requirements.
>
> Thanks for your time,
>
> Andy
>
>
>
>
>
> Martin Taal wrote:
>
>> Hi Andy,
>> Ed has answered already most of your questions. For your question
>> regarding
> live projects. I have
>> used Teneo over the past 2 years in one of my main projects I am
>> working on
> (a 1000+ user business
>> app for a large building company) and it has worked without problems
>> for me.
>
>> Just as Ed says new developments take place in the 0.8.0 branch but I
>> will
> continue to solve
>> blocking issues in the 0.7.5 branch.
>
>> Regarding your 4th question. Teneo offers automatic mapping of your
>> domain
> model to hibernate. In
>> addition it integrates EMF at runtime with Hibernate. The mapping
>> logic can
> be influenced with
>> annotations. You can also initially create a mapping through Teneo and
>> then
> for the rest maintain it
>> by hand.
>> The runtime integration is for supporting EMF lists
> (bidirectional/containment etc.) and specific
>> emf types (enums, anytype, datetype). In addition Teneo supports EMF
> FeatureMaps which is important
>> as more advanced xml schema constructs (multi-occ choice for example) are
> solved with a featuremap.
>
>> As a tip assuming that you would want to update the db with your detached
> instances. Hibernate needs
>> to know if an instance is already present in the db or not (otherwise
> updating results in creation
>> of new instances in the db).
>> It does this by checking the id or version property of an instance. In
>> case
> of detached instances
>> the id and version property have to be explicitly modeled. If this is a
> blocking issue (i.e. you
>> don't control the model) there are probably workarounds to be found (as
> Hibernate is very
>> extendable) but adding id/version as a model element is the
> preferred/easiest way.
>
>> gr. Martin
>
>> Ed Merks wrote:
>>> Andy,
>>>
>>> I think EMF compare should be able to do exactly what you describe.
>>> If the database can change out from under you while editing you could
>>> obviously end up with an incoherent set of changes, so doing a
>>> careful merge will be especially important. The general differencing
>>> problem is a very hard one, so it's really best to reuse what's
>>> provided and help improve it if there are any shortcomings...
>>>
>>>
>>> Andrew Steady wrote:
>>>> Hi Ed,
>>>>
>>>> Thanks for response... lots to consider, but immediately I wanted to
>>>> clarify our detached mode of working. We can't collate changes in
>>>> the detached mode as you suggest because the DB may change in
>>>> between. For that reason we need to create a delta between whats in
>>>> memory/xml and whats in the DB.
>>>>
>>>> I haven't heard of any OR/Rel mapping tool giving the delta instead
>>>> of making the updates so I figure we need to do the comparison in
>>>> memory ourselves so we can make the delta portable and show the user
>>>> the differences.
>>>>
>>>> Doesn't seem like EMF compare gives you the differences between two
>>>> sets of instances so we may need to write that logic ourselves -
>>>> shouldn't be too taxing.
>>>>
>>>> As for Teneo, sounds good then - if the versions will be compatible
>>>> for 1.4/3.2 (I'll investigate further), we'll give it a go...
>>>>
>>>> Thanks for your time as always,
>>>>
>>>> Andy
>>>>
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: Teneo / Hibernate / Compare [message #609816 is a reply to message #97292] |
Wed, 26 September 2007 02:14 |
| Eclipse User |
|
|
|
Originally posted by: andrew_steady.hotmail.com
Hi Martin,
We use containment relationships and Elists extensively. However I think
the fact that we do not need any run time functionality/integration (just
bulk conversions) between EMF and the DB means we can map directly to our
EMF classes. I have now tried this out and it works directly for
everything except lists, where I've had to add a dummy property and
setters/getters so that the getters can return a Set rather than a EList.
We'll find out if this approach will run into more problems as our OR
mappings get more complex.
Thanks for you advice,
Andy
Martin Taal wrote:
> Hi Andy,
> It all depends on how much the db schema differs from the automatic mapping.
Teneo will generate a
> hbm file (in memory but you easily get to it) so it can help you to get
started from there. The
> mapping will contain column/table names etc so then it is only to change
those (assuming that the
> structure of the db is similar).
> Teneo runtime (which can use a manually created mapping file) offers support
for the emf featuremap,
> anytype and EMF list implementations (bi-directional/containment). It is
possible that in your case
> bi-directional/containment lists do not apply. In that case there is less
need for Teneo runtime. I
> would test this out without Teneo and see how far you get.
> gr. Martin
> Andrew Steady wrote:
>> Hi Martin,
>>
>> We will maintain the primary key in our XML editing mode, and for new
>> objects we be given a key before saving. Thus when we save our detached
>> objects vanilla Hibernate can tell whether to update or insert easily -
>> I tested this.
>> Our DB schema is pre-existing and we cannot change it, so we need to map
>> the EMF objects to that rather than (auto)generate a new schema.
>>
>> So I don't see that we would benefit from the automatic mapping and
>> run-time integration teneo offers.
>> To summise we just want to be able to create new EMF instances with data
>> from the DB and then edit them locally persisting in XML, and on a
>> specific request save those detached instances (containing the primary
>> keys), all to our existing schema.
>>
>> Is there any reason why we couldn't map hibernate directly to our EMF
>> objects without Teneo? I'm trying to understand what support we would
>> get from Teneo given our requirements.
>>
>> Thanks for your time,
>>
>> Andy
>>
>>
>>
>>
>>
>> Martin Taal wrote:
>>
>>> Hi Andy,
>>> Ed has answered already most of your questions. For your question
>>> regarding
>> live projects. I have
>>> used Teneo over the past 2 years in one of my main projects I am
>>> working on
>> (a 1000+ user business
>>> app for a large building company) and it has worked without problems
>>> for me.
>>
>>> Just as Ed says new developments take place in the 0.8.0 branch but I
>>> will
>> continue to solve
>>> blocking issues in the 0.7.5 branch.
>>
>>> Regarding your 4th question. Teneo offers automatic mapping of your
>>> domain
>> model to hibernate. In
>>> addition it integrates EMF at runtime with Hibernate. The mapping
>>> logic can
>> be influenced with
>>> annotations. You can also initially create a mapping through Teneo and
>>> then
>> for the rest maintain it
>>> by hand.
>>> The runtime integration is for supporting EMF lists
>> (bidirectional/containment etc.) and specific
>>> emf types (enums, anytype, datetype). In addition Teneo supports EMF
>> FeatureMaps which is important
>>> as more advanced xml schema constructs (multi-occ choice for example) are
>> solved with a featuremap.
>>
>>> As a tip assuming that you would want to update the db with your detached
>> instances. Hibernate needs
>>> to know if an instance is already present in the db or not (otherwise
>> updating results in creation
>>> of new instances in the db).
>>> It does this by checking the id or version property of an instance. In
>>> case
>> of detached instances
>>> the id and version property have to be explicitly modeled. If this is a
>> blocking issue (i.e. you
>>> don't control the model) there are probably workarounds to be found (as
>> Hibernate is very
>>> extendable) but adding id/version as a model element is the
>> preferred/easiest way.
>>
>>> gr. Martin
>>
>>> Ed Merks wrote:
>>>> Andy,
>>>>
>>>> I think EMF compare should be able to do exactly what you describe.
>>>> If the database can change out from under you while editing you could
>>>> obviously end up with an incoherent set of changes, so doing a
>>>> careful merge will be especially important. The general differencing
>>>> problem is a very hard one, so it's really best to reuse what's
>>>> provided and help improve it if there are any shortcomings...
>>>>
>>>>
>>>> Andrew Steady wrote:
>>>>> Hi Ed,
>>>>>
>>>>> Thanks for response... lots to consider, but immediately I wanted to
>>>>> clarify our detached mode of working. We can't collate changes in
>>>>> the detached mode as you suggest because the DB may change in
>>>>> between. For that reason we need to create a delta between whats in
>>>>> memory/xml and whats in the DB.
>>>>>
>>>>> I haven't heard of any OR/Rel mapping tool giving the delta instead
>>>>> of making the updates so I figure we need to do the comparison in
>>>>> memory ourselves so we can make the delta portable and show the user
>>>>> the differences.
>>>>>
>>>>> Doesn't seem like EMF compare gives you the differences between two
>>>>> sets of instances so we may need to write that logic ourselves -
>>>>> shouldn't be too taxing.
>>>>>
>>>>> As for Teneo, sounds good then - if the versions will be compatible
>>>>> for 1.4/3.2 (I'll investigate further), we'll give it a go...
>>>>>
>>>>> Thanks for your time as always,
>>>>>
>>>>> Andy
>>>>>
>>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 13:25:22 GMT 2024
Powered by FUDForum. Page generated in 1.24420 seconds |
] 
Search
Help
Register
Login
Home
