db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Taal <mt...@springsite.com>
Subject Re: Specific User Collection Classes and get/set approach, when trying to use ojb with EMF objects
Date Wed, 06 Apr 2005 10:35:34 GMT
Hi Thomas,
Thanks for your reply.

Adding my own Collection impl. (inheriting from EMF and implementing the 
required ojb interface) is not possible because the type of the 
collection is not known until runtime and the EMF collection classes do 
not have empty constructors (see below).

I try to build a generic integration between emf and ojb so that classes 
generated by emf are persistable using ojb with no additional hand 
coding. EMF does not generate a set method for collection members. The 
collection can be retrieved using the get method and adapted directly. 
This I think is a clean approach of EMF.

As mentioned I made a small change (5-6 lines) to the retrieveCollection 
method of ojb QueryReferenceBroker to get this working for me but I do 
not want to keep my own copy of this class. Is there a possibility to 
send this as a patch or let this be reviewed (just trying :-).
However, I nicer approach than I implemented would work with collection 
factories or so.

Are there any ideas to make the QueryReferenceBroker/collection creation 
more pluggable which I can work with?
I am also willing to try things out or code myself if this would help 
out here.

gr. Martin

PS EMF Collections are very specific because they handle unique 
constraints and relationship logic (containment etc.). As an example: 
the creation of an EMF list (source code generated by emf) for the 
member Remark which contains a list of StringTypes, EList is an interface.

/** the member itself */
protected EList remark = null;

public EList getRemark() {
	if (remark == null) {
		remark = new EObjectContainmentEList(StringType.class, this, 
	return remark;

Thomas Dudziak wrote:
> On Apr 5, 2005 4:31 PM, Martin Taal <mtaal@springsite.com> wrote:
>>I am trying to use ojb to store objects generated by EMF (framework to
>>generate java source code based on UML/xsd schemas, see the eclipse
>>I have already covered some ground and am able to generate classes from
>>a few simple xsd's (using emf), automatically generate the database
>>scheme using the EMF specific javadoc tags (for all three inheritance
>>mapping strategies), generate the sql files to create the database
>>tables (using torque) and automatically generate ojb descriptor files to
>>map from the tables to the EMF objects.
>>Simple 1:1 references work (storage and retrieval), in addition storing
>>objects with 1:n references work.
>>However, retrieving an object with 1:n reference fails, because EMF
>>generated java classes do not have set methods for collection members.
>>Only a get method is generated (with a higher-level interface as the
>>return type). EMF generates the body of the get method and there creates
>>a specific List implementation which is invisible from the outside
>>(therefore I can not use the collection-class attribute in the
>>To get this working I have adapted the retrieveCollection method of the
>>org.apache.ojb.broker.core.QueryReferenceBroker class (as a test).
>>In this approach I check if the get method of the member returns a valid
>>List class (object) and if so call the add method on this returned List
>>to fill the member.
>>This works for this test case but is surely not the nicest/most robust
>>approach. Also I (ofcourse) do not want to have my own specific
>>implementation of this ojb class.
>>What possibly would work better here is sort of collection factory which
>>receives the class descriptor, collection descriptor and the object and
>>returns an empty collection, or even handles the whole add action. This
>>would also be in line with the idea of the object factory which can be
>>registered from the 'outside' (which I also use to get the right EMF
>>Is this possible in ojb in one way or the other or are there plans to
>>add this?
>>Or maybe there is another better solution of which I did not think.
> I'm not really familiar with EMF, but from what I've seen in the EMF
> javadoc, you might perhaps be able to specify your own subclass of
> EList for EMF to use, which in turn derives from one of OJB's
> collection classes. To me this way seems easiest because you'd only
> have to implement the additional move in this list
> Or if EMF requires something more involved, e.g. that you subclass
> EObjectEList, you do it the other way around: create a subclass of the
> EMF collection type that implements OJB's ManageableCollection
> interface.
> Tom
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org


With Regards, Martin Taal

Barchman Wuytierslaan 72b
3818 LK Amersfoort
tel: +31 (0)33 462 02 07
fax: +31 (0)33 463 77 12
Mobile: +31 (0)6 288 48 943
email: mtaal@springsite.com
web: www.springsite.com

To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message