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 22:52:29 GMT
Hi Thomas,
Thanks again for your time. I hope you can still help me a bit further.

I can try to get EMF to put my own combined EMF/OJB collection class in 
that location. However ojb is still responsible for the instantiation of 
the collection and expects a zero-argument constructor which is not 
offered by EMF.
Also afterwards going through the emf code by hand to change the list 
class or manually add zero-constructor list classes for specific members 
is not the approach I am looking for because I try to implement a 
generic layer which requires no hand coding for this model specific 
part. Also the query customizer helps to get the right content of the 
list but does not influence the list object used (as far as I could see).

I looked at the use of the ManageableCollection and its interface (and 
use) does not seem to complex (it has two add methods and one 
getIterator). The documentation lists also an afterStore method but I 
could not find that in the source code. The removal aware collections 
broker.util.collections need a bit more attention but are also doable 
for user-specific collections.

However for the user defined CollectionClass ojb assumes a zero-argument 
constructor. So, just trying again, but does a collection factory not 
make sense (returning either a ManageableCollection or a removal aware 
variant)? With a collection factory the user has much more 
control/flexibility when creating Collection objects.

Ojb supports the concept of ObjectFactories and to me the instantiation 
approach of a user specific object or a user specific collection is not 
that different.

The collection factory could be defined in the CollectionDescriptor just 
as the user defined CollectionClass. The user-defined CollectionClass 
(implementing the ManagableCollection) is only used in a few places in 
ojb (CollectionPrefetcher, MtoNCollectionPrefetcher and 
QueryReferenceBroker). So to replace this with a user-defined factory 
approach, only isolated changes are required. Or did I miss something here?

Again thanks for your time!

gr. Martin

Thomas Dudziak wrote:
>>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).
> 
> 
> But if I look at the code snippet you provided, I see that the used
> collection type is EObjectContainmentEList and its usage is fixed
> (i.e. specified in the class and instantiated via new). Now if you can
> configure the class that EMF puts there, then you can use your own
> OJB-adapted implementations, e.g. OjbEObjectContainmentEList ?
>  
> 
>>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 :-).
> 
> 
> Sure, just send it to the dev list. But please make sure that the unit
> tests pass as before.
> 
> 
>>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.
> 
> 
> Mhmm, the main problem is that OJB sets its own collection types in
> order to maintain information about which sub-objects need to be
> persisted and so on. You should have a look at the usage of
> ManageableCollection to see what OJB does with collections.
> Also you might want to have a look at the query customizer
> functionality; for both you'll find some documentation in this and the
> next paragraph here:
> 
> http://db.apache.org/ojb/docu/guides/advanced-technique.html#manageable-collection
> 
> 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

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: 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


Mime
View raw message