Eclipse Community Forums: EMF » CDO Regeneration and member fields

Home » Modeling » EMF » CDO Regeneration and member fields(Questions on the removal of member fields during CDO regeneration)

Show: Today's Messages :: Show Polls :: Message Navigator

CDO Regeneration and member fields [message #963534]

Mon, 29 October 2012 22:18

Andrew Whelan

Messages: 71
Registered: October 2012
Location: Syracuse NY

Member

Hello,

I am working on a project that makes heavy use of EMF. Development has been going on for a while and we are just getting around to determining what to do about a database store. So we already have a fairly large EMF Ecore model. We are considering CDO for database access. Member fields of the generated EMF classes disappear when we regenerate the code. I've seen this noted in a FAQ but I can't seem to find much information beyond this.

It's important to note that we are making use of the reflective delegation in our code. For the regenerated code, is fixing the removal of member valuables as simple as replacing them and using the @generated NOT annotation to keep it from happening again? Or is there something more? For instance, my code had a string field called "upper". The following field was generated as part of the unsettable functionality to support the "upper" string field I had.

protected boolean upperESet;

Is there some mechanism in CDO that makes this field useless now or is its purpose handled some other way in CDO?
Thanks
-Andrew

Report message to a moderator

Re: CDO Regeneration and member fields [message #963841 is a reply to message #963534]

Tue, 30 October 2012 04:13

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Am 29.10.2012 23:18, schrieb Andrew Whelan:
> Hello,
>
> I am working on a project that makes heavy use of EMF. Development has been going on for a while and we are just
> getting around to determining what to do about a database store. So we already have a fairly large EMF Ecore model. We
> are considering CDO for database access. Member fields of the generated EMF classes disappear when we regenerate the
> code. I've seen this noted in a FAQ but I can't seem to find much information beyond this.
On http://www.eclipse.org/cdo/documentation/presentations you can find a Webinar entry that is a little older but the
fundamentals of these mechanisms in CDO haven't changed for years.

> It's important to note that we are making use of the reflective delegation in our code. For the regenerated code, is
> fixing the removal of member valuables as simple as replacing them and using the @generated NOT annotation to keep it
> from happening again?
This removal is nothing that needs "fixing", it's really intentional because the generated reference fields and
EList-typed fields are based on Java strong references that would keep the entire model in memory. CDO stores the model
values differently and the fields are not needed anymore. Marking them @generated NOT defeats the whole purpose of CDO.

> Or is there something more? For instance, my code had a string field called "upper". The following field was generated
> as part of the unsettable functionality to support the "upper" string field I had.
>
> protected boolean upperESet;
>
> Is there some mechanism in CDO that makes this field useless now
Yes.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

> or is its purpose handled some other way in CDO? Thanks
> -Andrew
>

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Previous Topic:	[CDO] "an automatic schema migration mechanism"
Next Topic:	Creating EInt, EString, EDouble programmatically in Java

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 11:58:57 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter