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, CatalogPackage.PRODUCT_TYPE__REMARK);
}
return remark;
}
Thomas Dudziak wrote:
On Apr 5, 2005 4:31 PM, Martin Taal <[EMAIL PROTECTED]> wrote:
Hi, 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 project). 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 collection-descriptor).
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 objects). 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
With Regards, Martin Taal
Springsite 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: [EMAIL PROTECTED] web: www.springsite.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
