Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: domain of tomdzk@gmail.com designates
 64.233.170.207 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=MzClLzrUlaqC/hxGNLjNHdlG9E6YYzBMp+nfz3OyMdGCd1umRba/0KCwW7zo8hhnlEjCh6PXHCZ/r5jaa2tHEpWJNE0Ekc4Ra49SwpL+0J7s/sU6zZkyoVxpDKMHW8zMpPr1KtsprKdGN+lpvk1WCj7ukocqTVJy47r76rVP8eE=
Message-ID: <224f3234050405152339bfcca4@mail.gmail.com>
Date: Wed, 6 Apr 2005 00:23:19 +0200
From: Thomas Dudziak <tomdzk@gmail.com>
Reply-To: Thomas Dudziak <tomdzk@gmail.com>
To: OJB Developers List <ojb-dev@db.apache.org>
Subject: Re: Specific User Collection Classes and get/set approach,
 when trying to use ojb with EMF objects
In-Reply-To: <4252A14E.7090507@springsite.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
References: <4252A14E.7090507@springsite.com>

On Apr 5, 2005 4:31 PM, Martin Taal <mtaal@springsite.com> 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: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org