You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Martin Taal <mt...@springsite.com> on 2005/04/05 16:31:42 UTC
Specific User Collection Classes and get/set approach, when trying
to use ojb with EMF objects
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.
--
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
Re: Specific User Collection Classes and get/set approach, when trying to use ojb with EMF objects
Posted by Thomas Dudziak <to...@gmail.com>.
On Apr 7, 2005 11:58 AM, Martin Taal <mt...@springsite.com> wrote:
> Hi Thomas,
> I am looking at the HEAD version is this 1.1 (I am not that much of a
> cvs expert)?
Yup, CVS head is 1.1.
> No problem I will enter a feature request in jira and also attach some
> code (tested and all).
Great, I'll look into it then.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Specific User Collection Classes and get/set approach, when trying
to use ojb with EMF objects
Posted by Martin Taal <mt...@springsite.com>.
Hi Thomas,
I am looking at the HEAD version is this 1.1 (I am not that much of a
cvs expert)?
No problem I will enter a feature request in jira and also attach some
code (tested and all).
gr. Martin
Thomas Dudziak wrote:
> On Apr 7, 2005 12:52 AM, Martin Taal <mt...@springsite.com> wrote:
>
>>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).
>
>
> There is no way to configure which collection classes EMF uses ?
> Honestly, that would be stupid design on part of the EMF folks. But
> anyway ...
>
>
>>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.
>
>
> Might be a leftover bit of documentation, the afterStore was present
> in the 1.0 branch.
>
>
>>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?
>
>
> Mhmm, should be doable without that much effort then. Could you
> perhaps create a feature request in JIRA for this, stating some
> requirements that you would have for such a collection factory ? And
> if you happen to have some code that you could attach at the feature
> request :-)
>
> Btw, we're talking about OJB 1.1 here, right ?
>
> 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
Re: Specific User Collection Classes and get/set approach, when trying to use ojb with EMF objects
Posted by Thomas Dudziak <to...@gmail.com>.
On Apr 7, 2005 12:52 AM, Martin Taal <mt...@springsite.com> wrote:
> 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).
There is no way to configure which collection classes EMF uses ?
Honestly, that would be stupid design on part of the EMF folks. But
anyway ...
> 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.
Might be a leftover bit of documentation, the afterStore was present
in the 1.0 branch.
> 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?
Mhmm, should be doable without that much effort then. Could you
perhaps create a feature request in JIRA for this, stating some
requirements that you would have for such a collection factory ? And
if you happen to have some code that you could attach at the feature
request :-)
Btw, we're talking about OJB 1.1 here, right ?
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Specific User Collection Classes and get/set approach, when trying
to use ojb with EMF objects
Posted by Martin Taal <mt...@springsite.com>.
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
Re: Specific User Collection Classes and get/set approach, when trying to use ojb with EMF objects
Posted by Thomas Dudziak <to...@gmail.com>.
> 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
Re: Specific User Collection Classes and get/set approach, when trying
to use ojb with EMF objects
Posted by Martin Taal <mt...@springsite.com>.
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 <mt...@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
>
>
>
--
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
Re: Specific User Collection Classes and get/set approach, when trying to use ojb with EMF objects
Posted by Thomas Dudziak <to...@gmail.com>.
On Apr 5, 2005 4:31 PM, Martin Taal <mt...@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