Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » CDO Regeneration and member fields(Questions on the removal of member fields during CDO regeneration)
CDO Regeneration and member fields [message #963534] Mon, 29 October 2012 18:18 Go to next message
Andrew Whelan is currently offline Andrew Whelan
Messages: 69
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
Re: CDO Regeneration and member fields [message #963841 is a reply to message #963534] Tue, 30 October 2012 00:13 Go to previous message
Eike Stepper is currently offline Eike Stepper
Messages: 5486
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
>
Previous Topic:[CDO] "an automatic schema migration mechanism"
Next Topic:Creating EInt, EString, EDouble programmatically in Java
Goto Forum:
  


Current Time: Sat Aug 02 00:46:17 EDT 2014

Powered by FUDForum. Page generated in 0.01687 seconds