Re: Problem with 1:m relation (ODMG, DList)
[EMAIL PROTECTED] wrote:
Hi,
I´ve must be really stupid but, after read tutorials, eMails, source code...
I´ve not be able to run my 1:m code.
Two classes A and B, with A --- B relation (1:m)
public class A
{
private int id;
private DList listB;
private String name;
public void A()
{
listB = new DListImpl() is this correct or must be use
OJB.getInstance().newDList()???
}
}
Do you rely on using DList? Or what about
/**
* @ojb.collection element-class-ref=B
* foreignkey=idA
* orderby=id
*/
private List listB = new Vector();
--
Christian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with 1:m relation (ODMG, DList)
Ok, I´ve just to rewrite all code with PB api, using Vector and
RemovalAwareCollection and it works
But, why do not DList and ODMW work? I´ve seen DListImplementatio source
code and I don´t recongnize any piece of code to call ODMG (PB) api..
jose Galiana
[EMAIL PROTECTED] wrote:
Hi,
I´ve must be really stupid but, after read tutorials, eMails, source
code... I´ve not be able to run my 1:m code.
Two classes A and B, with A --- B relation (1:m)
public class A
{
private int id;
private DList listB;
private String name;
public void A()
{
listB = new DListImpl() is this correct or must be use
OJB.getInstance().newDList()???
}
}
Do you rely on using DList? Or what about
/**
* @ojb.collection element-class-ref=B
* foreignkey=idA
* orderby=id
*/
private List listB = new Vector();
--
Christian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with 1:m relation (ODMG, DList)
[EMAIL PROTECTED] wrote: Ok, I´ve just to rewrite all code with PB api, using Vector and RemovalAwareCollection and it works Try to use the ODMG instead of the PB API now. That worked for me, too. But I had problems using HashSet for collections (see previous mail Collection problem from 07.08.2003). -- Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with 1:m relation (ODMG, DList)
Hi,
I´ve must be really stupid but, after read tutorials, eMails, source code...
I´ve not be able to run my 1:m code.
Two classes A and B, with A --- B relation (1:m)
public class A
{
private int id;
private DList listB;
private String name;
public void A()
{
listB = new DListImpl() is this correct or must be use
OJB.getInstance().newDList()???
}
}
public class B
{
private int id;
private int idA;
private A a;
}
In repository.xml must I put a reference-descriptor in class-descriptor for
class B?
reference-descriptor name=a classref=es.jgm.docmanager.db.empresa.A
foreignkey field-ref=idA/
/reference-descriptor
In collection-descriptor for class A I´ve put
org.apache.ojb.odmg.collections.DListImpl
1) I create a new A object and store in DB using ODMG api.
2) I create a DList using odmg.newDList();
3) Retrieve all B objcets from DB
4) Iterate from all B objects and put the A id in B idA
5) Set list.add( b ) for each iteration
6) Add list in A using setListB( list )
7) Store A
Nothing happends.
I´ve tried without 4) point´, I´ve tried to put B.setA( a ) in point 4),
I´ve tried both ( setIdA() and setA() ) in point 4)
I´ve tried to clean the cache before, during, after to obtain de objects (A
and B-collection) from database.
Nothing happends.
I´ve using ojb rc4, jdk 1.4.1_01, MySql.
Any idea?
Greetings
Jose Galiana
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1:m-relation
Yes, exactly what I do. But see, to B instances be stored in database, you
must put auto-update='true' in your collection descriptor.
In real, I use a collection class RemovalAwareCollection (or a specialized
RemovalAwareList that I've created) to auto-delete. So, if I
a.getCol().remove( 0 );
broker.store(a);
the item in 0 is deleted from database, as expected. This is a must for my
app.
Best regards,
Edson Richter
- Original Message -
From: James Nyika [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 4:46 PM
Subject: Re: 1:m-relation
Edson,
Can i ask you to give an example of how you add more B objects the the
collection you described below
do you do something like this :
//get broker
broker = brokerfactory.defaultInstance();
//fetch an A object that has say 3 B objects in the collection.
...
//create a new B object
B newB = new B();
//add to the collection
A.getCol().add(newB);
//persist the A
broker.beginTransaction();
broker.store(A);
broker.commitTransaction();
?
James Nyika
Cambridge Technology Partners
The global eServices company of Novell, Inc.
http://www.novell.com
[EMAIL PROTECTED] 7/8/2003 12:24:28 PM
Hi!
I'm largelly using 1:N and M:N relationships in my project. I'll try to
give
you a little tips:
1) Use your N parts as Collection. If you are using
PersistentFieldPropertyImpl, then you should have
public class A {
private Collection myNpart;
private Integer id;
public void setId( Integer newId ) { id = newId; }
public Integer getId( ) {return id;}
public void setCol( Collection newCol ) { myNpart = newCol; }
public Collection getCol( ) { return myNpart; }
}
public class B {
private Integer id;
private Integer idA;
private A a;
public void setId( Integer newId ) { id = newId; }
public Integer getId( ) {return id;}
public void setIdA( Integer newIdA ) { idA = newIdA; }
public Integer getIdA( ) {return idA;}
public void setA( A newA ) { a = newA; }
public A getA( ) { return a; }
}
2) Your .xml should be similar to:
class-descriptor
class=A
table=TB_A
field-descriptor
name=id
column=ID
jdbc-type=INTEGER
primarykey=true /
collection-descriptor
name=col
element-class-ref=B
inverse-foreignkey
field-ref=idA/
/collection-descriptor
/class-descriptor
class-descriptor
class=B
table=TB_B
field-descriptor
name=id
column=ID
jdbc-type=INTEGER
primarykey=true /
field-descriptor
name=idA
column=ID_A
jdbc-type=INTEGER
primarykey=true /
reference-descriptor
name=a
class-ref=A
foreignkey field-ref=idA/
/reference-descriptor
/class-descriptor
And this should work. You don't need to specify auto-retrieve, because
by
default it's true. Auto-update and auto-delete are false by default.
Some
people like to work with specialized collection classes. In particular,
I
work always with RemovalAwareList (a collection that know how to
persists
deletes in the collection). To archieve this, your should be more
specific
in collection descriptor like this:
collection-descriptor
name=col
collection-class=org.apache.ojb.broker.util.collections.RemovalAwareList
element-class-ref=B
inverse-foreignkey
field-ref=idA/
/collection-descriptor
Of course, you could mixes the several other options that OJB offers to
you,
like auto-increment, proxies and so on. In this case, I'll recomendly
you to
use cvs HEAD that has several fixes for these options over rc3.
Best regards,
Edson Richter
- Original Message -
From: Christian Eugster [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, July 07, 2003 11:31 AM
Subject: 1:m-relation
i am working on a mysql-database and ojb rc3. i have an 1:m-relation
with
the following setting in the collection-desriptor of the parent
object:
auto-retrieve=true
when i try to retrieve an parent-object i get the error-message as
follows:
(setting auto-retrieve to false there is no error). what am i doing
wrong?
java.lang.IllegalArgumentException
at
sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.
java:63)
at java.lang.reflect.Field.set(Field.java:519)
at
org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDefaultImpl.set(Un
known Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.retrieveCollection(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.retrieveCollections(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(Unknown
Source)
at org.apache.ojb.broker.accesslayer.RsIterator.next(Unknown Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source
Re: 1:m-relation
Edson,
see this is very interesting because i do not use any special
collection class. I use a simple
vector. When i do the stuff you are describing below, my new B object
is not being created in
the database, EVEN with my auto-update set to true. If i change
anything on the A object, the change
is recognized and saved. However, if i add or remove any objects from
the collection of B objects, it is as through
the change is not recognized. Should i start using the
RemovalAwareCollection in order to make sure that any additions
or deletions to the vector ?
Note: the difference between what i showed below and the examples that
come with OJB is that OJB examples always show the
changes being made in the context of a broker transaction. I am not
sure if this matters, but the way i am writing my interface to the
persistence broker, i would like to be able to read objects out of the
database, update them at will outside of broker transaction contexts,
then
bring the same references back and save the altered objects back to
the database.
any help you can provide would be helpful
James Nyika
Cambridge Technology Partners
The global eServices company of Novell, Inc.
http://www.novell.com
[EMAIL PROTECTED] 7/9/2003 6:31:08 AM
Yes, exactly what I do. But see, to B instances be stored in database,
you
must put auto-update='true' in your collection descriptor.
In real, I use a collection class RemovalAwareCollection (or a
specialized
RemovalAwareList that I've created) to auto-delete. So, if I
a.getCol().remove( 0 );
broker.store(a);
the item in 0 is deleted from database, as expected. This is a must for
my
app.
Best regards,
Edson Richter
- Original Message -
From: James Nyika [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 4:46 PM
Subject: Re: 1:m-relation
Edson,
Can i ask you to give an example of how you add more B objects the
the
collection you described below
do you do something like this :
//get broker
broker = brokerfactory.defaultInstance();
//fetch an A object that has say 3 B objects in the collection.
...
//create a new B object
B newB = new B();
//add to the collection
A.getCol().add(newB);
//persist the A
broker.beginTransaction();
broker.store(A);
broker.commitTransaction();
?
James Nyika
Cambridge Technology Partners
The global eServices company of Novell, Inc.
http://www.novell.com
[EMAIL PROTECTED] 7/8/2003 12:24:28 PM
Hi!
I'm largelly using 1:N and M:N relationships in my project. I'll try
to
give
you a little tips:
1) Use your N parts as Collection. If you are using
PersistentFieldPropertyImpl, then you should have
public class A {
private Collection myNpart;
private Integer id;
public void setId( Integer newId ) { id = newId; }
public Integer getId( ) {return id;}
public void setCol( Collection newCol ) { myNpart = newCol; }
public Collection getCol( ) { return myNpart; }
}
public class B {
private Integer id;
private Integer idA;
private A a;
public void setId( Integer newId ) { id = newId; }
public Integer getId( ) {return id;}
public void setIdA( Integer newIdA ) { idA = newIdA; }
public Integer getIdA( ) {return idA;}
public void setA( A newA ) { a = newA; }
public A getA( ) { return a; }
}
2) Your .xml should be similar to:
class-descriptor
class=A
table=TB_A
field-descriptor
name=id
column=ID
jdbc-type=INTEGER
primarykey=true /
collection-descriptor
name=col
element-class-ref=B
inverse-foreignkey
field-ref=idA/
/collection-descriptor
/class-descriptor
class-descriptor
class=B
table=TB_B
field-descriptor
name=id
column=ID
jdbc-type=INTEGER
primarykey=true /
field-descriptor
name=idA
column=ID_A
jdbc-type=INTEGER
primarykey=true /
reference-descriptor
name=a
class-ref=A
foreignkey field-ref=idA/
/reference-descriptor
/class-descriptor
And this should work. You don't need to specify auto-retrieve, because
by
default it's true. Auto-update and auto-delete are false by default.
Some
people like to work with specialized collection classes. In
particular,
I
work always with RemovalAwareList (a collection that know how to
persists
deletes in the collection). To archieve this, your should be more
specific
in collection descriptor like this:
collection-descriptor
name=col
collection-class=org.apache.ojb.broker.util.collections.RemovalAwareList
element-class-ref=B
inverse-foreignkey
field-ref=idA/
/collection-descriptor
Of course, you could mixes the several other options that OJB offers
to
you,
like auto-increment, proxies and so on. In this case, I'll recomendly
you to
use cvs HEAD that has several fixes for these options over rc3.
Best regards,
Edson Richter
- Original Message -
From: Christian
Re: 1:m-relation
Hi!
The persistence should occur automatically when auto-update=true, even using
Vectors.
Are you working with OJB Api, ODBC or JDO?
The samples I've shown uses OJB Api. And of course, I use transactions...
(or I store A and all instances of B, or don't store anything. This is a
must when working with large apps).
Maybe someone else can point you with more information... All that I can
tell you is that this work. When I started with OJB I've used the samples,
and they work. Maybe you have missing something in configuration.
About the RemovalAwareCollection, you should use only if you need the
instances of B being removed when you store A... Nothing about auto-update
inserting objects.
[]s
Edson Richter
- Original Message -
From: James Nyika [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 09, 2003 11:03 AM
Subject: Re: 1:m-relation
Edson,
see this is very interesting because i do not use any special
collection class. I use a simple
vector. When i do the stuff you are describing below, my new B object
is not being created in
the database, EVEN with my auto-update set to true. If i change
anything on the A object, the change
is recognized and saved. However, if i add or remove any objects from
the collection of B objects, it is as through
the change is not recognized. Should i start using the
RemovalAwareCollection in order to make sure that any additions
or deletions to the vector ?
Note: the difference between what i showed below and the examples that
come with OJB is that OJB examples always show the
changes being made in the context of a broker transaction. I am not
sure if this matters, but the way i am writing my interface to the
persistence broker, i would like to be able to read objects out of the
database, update them at will outside of broker transaction contexts,
then
bring the same references back and save the altered objects back to
the database.
any help you can provide would be helpful
James Nyika
Cambridge Technology Partners
The global eServices company of Novell, Inc.
http://www.novell.com
[EMAIL PROTECTED] 7/9/2003 6:31:08 AM
Yes, exactly what I do. But see, to B instances be stored in database,
you
must put auto-update='true' in your collection descriptor.
In real, I use a collection class RemovalAwareCollection (or a
specialized
RemovalAwareList that I've created) to auto-delete. So, if I
a.getCol().remove( 0 );
broker.store(a);
the item in 0 is deleted from database, as expected. This is a must for
my
app.
Best regards,
Edson Richter
- Original Message -
From: James Nyika [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 4:46 PM
Subject: Re: 1:m-relation
Edson,
Can i ask you to give an example of how you add more B objects the
the
collection you described below
do you do something like this :
//get broker
broker = brokerfactory.defaultInstance();
//fetch an A object that has say 3 B objects in the collection.
...
//create a new B object
B newB = new B();
//add to the collection
A.getCol().add(newB);
//persist the A
broker.beginTransaction();
broker.store(A);
broker.commitTransaction();
?
James Nyika
Cambridge Technology Partners
The global eServices company of Novell, Inc.
http://www.novell.com
[EMAIL PROTECTED] 7/8/2003 12:24:28 PM
Hi!
I'm largelly using 1:N and M:N relationships in my project. I'll try
to
give
you a little tips:
1) Use your N parts as Collection. If you are using
PersistentFieldPropertyImpl, then you should have
public class A {
private Collection myNpart;
private Integer id;
public void setId( Integer newId ) { id = newId; }
public Integer getId( ) {return id;}
public void setCol( Collection newCol ) { myNpart = newCol; }
public Collection getCol( ) { return myNpart; }
}
public class B {
private Integer id;
private Integer idA;
private A a;
public void setId( Integer newId ) { id = newId; }
public Integer getId( ) {return id;}
public void setIdA( Integer newIdA ) { idA = newIdA; }
public Integer getIdA( ) {return idA;}
public void setA( A newA ) { a = newA; }
public A getA( ) { return a; }
}
2) Your .xml should be similar to:
class-descriptor
class=A
table=TB_A
field-descriptor
name=id
column=ID
jdbc-type=INTEGER
primarykey=true /
collection-descriptor
name=col
element-class-ref=B
inverse-foreignkey
field-ref=idA/
/collection-descriptor
/class-descriptor
class-descriptor
class=B
table=TB_B
field-descriptor
name=id
column=ID
jdbc-type=INTEGER
primarykey=true /
field-descriptor
name=idA
column=ID_A
jdbc-type=INTEGER
primarykey=true /
reference-descriptor
name=a
class-ref=A
foreignkey field-ref=idA/
/reference-descriptor
/class-descriptor
And this should work. You don't need to specify auto-retrieve
Re: 1:m-relation
hi christian, imo you have defined the setter for your collection as Vector. you should use Collection instead. jakob Christian Eugster wrote: i am working on a mysql-database and ojb rc3. i have an 1:m-relation with the following setting in the collection-desriptor of the parent object: auto-retrieve=true when i try to retrieve an parent-object i get the error-message as follows: (setting auto-retrieve to false there is no error). what am i doing wrong? java.lang.IllegalArgumentException at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl. java:63) at java.lang.reflect.Field.set(Field.java:519) at org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDefaultImpl.set(Un known Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.retrieveCollection(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.retrieveCollections(Unknown Source) at org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(Unknown Source) at org.apache.ojb.broker.accesslayer.RsIterator.next(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow n Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow n Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow n Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow n Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery( Unknown Source) at ch.eugster.pos.db.Receipt.getReceiptsByUserState(Receipt.java:183) at ch.eugster.pos.client.gui.ReceiptTableBlock.loadReceipts(ReceiptTableBlock.j ava:58) at ch.eugster.pos.client.gui.ReceiptTableBlock.init(ReceiptTableBlock.java:50) at ch.eugster.pos.client.gui.ReceiptTableBlock.init(ReceiptTableBlock.java:39 ) at ch.eugster.pos.client.gui.ChildrenBlock.init(ChildrenBlock.java:34) at ch.eugster.pos.client.gui.ChildrenBlock.init(ChildrenBlock.java:28) at ch.eugster.pos.client.gui.UserPanel.init(UserPanel.java:58) at ch.eugster.pos.client.gui.UserPanel.init(UserPanel.java:39) at ch.eugster.pos.client.gui.TabPanel.addUser(TabPanel.java:67) at ch.eugster.pos.client.gui.TabPanel.userLoggedIn(TabPanel.java:126) at ch.eugster.pos.client.gui.LoginPanel.fireLoginEvent(LoginPanel.java:99) at ch.eugster.pos.client.gui.LoginPanel.actionPerformed(LoginPanel.java:90) at ch.eugster.pos.client.gui.LoginBlock.fireActionEvent(LoginBlock.java:197) at ch.eugster.pos.client.gui.LoginBlock.keyPressed(LoginBlock.java:156) at java.awt.Component.processKeyEvent(Component.java:5051) at javax.swing.JComponent.processKeyEvent(JComponent.java:2385) at java.awt.Component.processEvent(Component.java:4902) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3598) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3439) at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1688 ) at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusMa nager.java:593) at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocu sManager.java:765) at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocu sManager.java:698) at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManag er.java:559) at java.awt.Component.dispatchEventImpl(Component.java:3468) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Window.dispatchEventImpl(Window.java:1585) at java.awt.Component.dispatchEvent(Component.java:3439) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.ja va:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java :150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) rethrown as org.apache.ojb.broker.metadata.MetadataException: Error setting field:positions in object:ch.eugster.pos.db.Receipt at org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDefaultImpl.set(Un known Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.retrieveCollection(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.retrieveCollections(Unknown Source) at org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(Unknown Source
Re: 1:m-relation
Edson,
Can i ask you to give an example of how you add more B objects the the
collection you described below
do you do something like this :
//get broker
broker = brokerfactory.defaultInstance();
//fetch an A object that has say 3 B objects in the collection.
...
//create a new B object
B newB = new B();
//add to the collection
A.getCol().add(newB);
//persist the A
broker.beginTransaction();
broker.store(A);
broker.commitTransaction();
?
James Nyika
Cambridge Technology Partners
The global eServices company of Novell, Inc.
http://www.novell.com
[EMAIL PROTECTED] 7/8/2003 12:24:28 PM
Hi!
I'm largelly using 1:N and M:N relationships in my project. I'll try to
give
you a little tips:
1) Use your N parts as Collection. If you are using
PersistentFieldPropertyImpl, then you should have
public class A {
private Collection myNpart;
private Integer id;
public void setId( Integer newId ) { id = newId; }
public Integer getId( ) {return id;}
public void setCol( Collection newCol ) { myNpart = newCol; }
public Collection getCol( ) { return myNpart; }
}
public class B {
private Integer id;
private Integer idA;
private A a;
public void setId( Integer newId ) { id = newId; }
public Integer getId( ) {return id;}
public void setIdA( Integer newIdA ) { idA = newIdA; }
public Integer getIdA( ) {return idA;}
public void setA( A newA ) { a = newA; }
public A getA( ) { return a; }
}
2) Your .xml should be similar to:
class-descriptor
class=A
table=TB_A
field-descriptor
name=id
column=ID
jdbc-type=INTEGER
primarykey=true /
collection-descriptor
name=col
element-class-ref=B
inverse-foreignkey
field-ref=idA/
/collection-descriptor
/class-descriptor
class-descriptor
class=B
table=TB_B
field-descriptor
name=id
column=ID
jdbc-type=INTEGER
primarykey=true /
field-descriptor
name=idA
column=ID_A
jdbc-type=INTEGER
primarykey=true /
reference-descriptor
name=a
class-ref=A
foreignkey field-ref=idA/
/reference-descriptor
/class-descriptor
And this should work. You don't need to specify auto-retrieve, because
by
default it's true. Auto-update and auto-delete are false by default.
Some
people like to work with specialized collection classes. In particular,
I
work always with RemovalAwareList (a collection that know how to
persists
deletes in the collection). To archieve this, your should be more
specific
in collection descriptor like this:
collection-descriptor
name=col
collection-class=org.apache.ojb.broker.util.collections.RemovalAwareList
element-class-ref=B
inverse-foreignkey
field-ref=idA/
/collection-descriptor
Of course, you could mixes the several other options that OJB offers to
you,
like auto-increment, proxies and so on. In this case, I'll recomendly
you to
use cvs HEAD that has several fixes for these options over rc3.
Best regards,
Edson Richter
- Original Message -
From: Christian Eugster [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, July 07, 2003 11:31 AM
Subject: 1:m-relation
i am working on a mysql-database and ojb rc3. i have an 1:m-relation
with
the following setting in the collection-desriptor of the parent
object:
auto-retrieve=true
when i try to retrieve an parent-object i get the error-message as
follows:
(setting auto-retrieve to false there is no error). what am i doing
wrong?
java.lang.IllegalArgumentException
at
sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.
java:63)
at java.lang.reflect.Field.set(Field.java:519)
at
org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDefaultImpl.set(Un
known Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.retrieveCollection(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.retrieveCollections(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(Unknown
Source)
at org.apache.ojb.broker.accesslayer.RsIterator.next(Unknown Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(
Unknown Source)
at ch.eugster.pos.db.Receipt.getReceiptsByUserState(Receipt.java:183)
at
ch.eugster.pos.client.gui.ReceiptTableBlock.loadReceipts(ReceiptTableBlock.j
ava:58)
at
ch.eugster.pos.client.gui.ReceiptTableBlock.init(ReceiptTableBlock.java:50)
at
ch.eugster.pos.client.gui.ReceiptTableBlock.init(ReceiptTableBlock.java:39
1:m-relation
i am working on a mysql-database and ojb rc3. i have an 1:m-relation with the following setting in the collection-desriptor of the parent object: auto-retrieve=true when i try to retrieve an parent-object i get the error-message as follows: (setting auto-retrieve to false there is no error). what am i doing wrong? java.lang.IllegalArgumentException at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl. java:63) at java.lang.reflect.Field.set(Field.java:519) at org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDefaultImpl.set(Un known Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.retrieveCollection(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.retrieveCollections(Unknown Source) at org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(Unknown Source) at org.apache.ojb.broker.accesslayer.RsIterator.next(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow n Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow n Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow n Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow n Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery( Unknown Source) at ch.eugster.pos.db.Receipt.getReceiptsByUserState(Receipt.java:183) at ch.eugster.pos.client.gui.ReceiptTableBlock.loadReceipts(ReceiptTableBlock.j ava:58) at ch.eugster.pos.client.gui.ReceiptTableBlock.init(ReceiptTableBlock.java:50) at ch.eugster.pos.client.gui.ReceiptTableBlock.init(ReceiptTableBlock.java:39 ) at ch.eugster.pos.client.gui.ChildrenBlock.init(ChildrenBlock.java:34) at ch.eugster.pos.client.gui.ChildrenBlock.init(ChildrenBlock.java:28) at ch.eugster.pos.client.gui.UserPanel.init(UserPanel.java:58) at ch.eugster.pos.client.gui.UserPanel.init(UserPanel.java:39) at ch.eugster.pos.client.gui.TabPanel.addUser(TabPanel.java:67) at ch.eugster.pos.client.gui.TabPanel.userLoggedIn(TabPanel.java:126) at ch.eugster.pos.client.gui.LoginPanel.fireLoginEvent(LoginPanel.java:99) at ch.eugster.pos.client.gui.LoginPanel.actionPerformed(LoginPanel.java:90) at ch.eugster.pos.client.gui.LoginBlock.fireActionEvent(LoginBlock.java:197) at ch.eugster.pos.client.gui.LoginBlock.keyPressed(LoginBlock.java:156) at java.awt.Component.processKeyEvent(Component.java:5051) at javax.swing.JComponent.processKeyEvent(JComponent.java:2385) at java.awt.Component.processEvent(Component.java:4902) at java.awt.Container.processEvent(Container.java:1566) at java.awt.Component.dispatchEventImpl(Component.java:3598) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Component.dispatchEvent(Component.java:3439) at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1688 ) at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusMa nager.java:593) at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocu sManager.java:765) at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocu sManager.java:698) at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManag er.java:559) at java.awt.Component.dispatchEventImpl(Component.java:3468) at java.awt.Container.dispatchEventImpl(Container.java:1623) at java.awt.Window.dispatchEventImpl(Window.java:1585) at java.awt.Component.dispatchEvent(Component.java:3439) at java.awt.EventQueue.dispatchEvent(EventQueue.java:450) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.ja va:197) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java :150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136) at java.awt.EventDispatchThread.run(EventDispatchThread.java:99) rethrown as org.apache.ojb.broker.metadata.MetadataException: Error setting field:positions in object:ch.eugster.pos.db.Receipt at org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDefaultImpl.set(Un known Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.retrieveCollection(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.retrieveCollections(Unknown Source) at org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(Unknown Source) at org.apache.ojb.broker.accesslayer.RsIterator.next(Unknown Source
Re: 1:m relation not updating
Hi again Shane Shane Mingins wrote: Hi Thomas These are probably going to be dumb questions but I cannot find answers anywhere. [The mail list archive is so frustrating to use.] 1. How do I lock 'b' elements from a collection using the ODMG API? tx.lock(b, Transaction.WRITE); 2. Can I double check regarding the collection-descriptor auto-retrieve/update/delete that in the Advanced O/R is states: These default settings are mandatory for proper operation of the ODMG and JDO implementation. that this means accept the defaults when using ODMG? (I get errors when I set auto-update=true, but when using deletePersistent(obj) I found setting auto-delete=true removed the 'b' elements but when not set the 'b' elements remained persisted. The above statement is really true don't use auto-update=true and auto-delete=true in ODMG. Setting them to true results in double execution of updates and deletes which agains results in the execptions you see. To delete B instance b use Database.deletePersistent(b); 3. As DList is abstract what would I use in a model object to store 'b' elements? I see where the Implementation object can create a new DList odmg.newDList() In your object you can type the attribute as DList. In the repository you have to declare the collection type as o.a.ojb.odmg.collections.DListImpl. odmg.newDList() instantiates a DListImpl. using this factory method is the ODMG way to instantiate a DList. cheers, Thomas Cheers Shane -Original Message- From: Thomas Mahler [mailto:[EMAIL PROTECTED] Sent: Wednesday, 11 June 2003 5:51 p.m. To: OJB Users List Subject: Re: 1:m relation not updating You have to lock the b elements too if you are using normal collections to hold the many-side of the association. If you were using DList as your collection class this won't be required. cheers, thomas Saman Ghodsian wrote: Hi there, Here is the situation.. Say I have class A and class B 1-m I created the repository.xml Everything works fine when storing A to DB with a couple of B's Tx.lock(a, Transaction.WRITE); Tx.Commit Next step is to load a and add more B's and then save it again. I created the query. And all a and the related B's get loaded ok Now I add a couple more B's And store a Tx.lock(a, Transaction.WRITE); Also tried Tx.lock(a, Transaction.UPGRADE); But the new B's don't get inserted in DB. Any ideas Thanks Sam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 1:m relation not updating
Hi Thomas, I roughly have the same problems, but slightly different senario. The child object is actually already in the database. I want to insert the parent object into the database, whereas update some field in the child object (The child record actually is there in database). How should I do it in ODMG api? Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 12 June 2003 14:17 To: OJB Users List Subject: Re: 1:m relation not updating Hi again Shane Shane Mingins wrote: Hi Thomas These are probably going to be dumb questions but I cannot find answers anywhere. [The mail list archive is so frustrating to use.] 1. How do I lock 'b' elements from a collection using the ODMG API? tx.lock(b, Transaction.WRITE); 2. Can I double check regarding the collection-descriptor auto-retrieve/update/delete that in the Advanced O/R is states: These default settings are mandatory for proper operation of the ODMG and JDO implementation. that this means accept the defaults when using ODMG? (I get errors when I set auto-update=true, but when using deletePersistent(obj) I found setting auto-delete=true removed the 'b' elements but when not set the 'b' elements remained persisted. The above statement is really true don't use auto-update=true and auto-delete=true in ODMG. Setting them to true results in double execution of updates and deletes which agains results in the execptions you see. To delete B instance b use Database.deletePersistent(b); 3. As DList is abstract what would I use in a model object to store 'b' elements? I see where the Implementation object can create a new DList odmg.newDList() In your object you can type the attribute as DList. In the repository you have to declare the collection type as o.a.ojb.odmg.collections.DListImpl. odmg.newDList() instantiates a DListImpl. using this factory method is the ODMG way to instantiate a DList. cheers, Thomas Cheers Shane -Original Message- From: Thomas Mahler [mailto:[EMAIL PROTECTED] Sent: Wednesday, 11 June 2003 5:51 p.m. To: OJB Users List Subject: Re: 1:m relation not updating You have to lock the b elements too if you are using normal collections to hold the many-side of the association. If you were using DList as your collection class this won't be required. cheers, thomas Saman Ghodsian wrote: Hi there, Here is the situation.. Say I have class A and class B 1-m I created the repository.xml Everything works fine when storing A to DB with a couple of B's Tx.lock(a, Transaction.WRITE); Tx.Commit Next step is to load a and add more B's and then save it again. I created the query. And all a and the related B's get loaded ok Now I add a couple more B's And store a Tx.lock(a, Transaction.WRITE); Also tried Tx.lock(a, Transaction.UPGRADE); But the new B's don't get inserted in DB. Any ideas Thanks Sam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1:m relation not updating
Thomas, I am experiencing the same problem but i am not using to ODMG api (as i think Saman was) but rather straight PersistenceBroker. 1. Should i change my Vector collections to use DList ? or how do you mean 'using DList' as your collection ? 2. WHen doing a proper 1-M mapping.. do i have to construct new children, point them back to their parent object (the reference-descriptor) and then add it to the collection then call store() on the parent ? thanks.. I had previously posted the same qn titled 1-M mappings but i never got a response from anyone thanks again James Nyika Cambridge Technology Partners The global eServices company of Novell, Inc. http://www.novell.com [EMAIL PROTECTED] 6/11/2003 1:51:21 AM You have to lock the b elements too if you are using normal collections to hold the many-side of the association. If you were using DList as your collection class this won't be required. cheers, thomas Saman Ghodsian wrote: Hi there, Here is the situation.. Say I have class A and class B 1-m I created the repository.xml Everything works fine when storing A to DB with a couple of B's Tx.lock(a, Transaction.WRITE); Tx.Commit Next step is to load a and add more B's and then save it again. I created the query. And all a and the related B's get loaded ok Now I add a couple more B's And store a Tx.lock(a, Transaction.WRITE); Also tried Tx.lock(a, Transaction.UPGRADE); But the new B's don't get inserted in DB. Any ideas Thanks Sam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1:m relation not updating
Sam I was having the same problem that you were... could you possibly email me your mapping of classes to tables for the two classes. I would like to cross check that at least my mapping configuration is similar to yours thanks James Nyika Cambridge Technology Partners The global eServices company of Novell, Inc. http://www.novell.com [EMAIL PROTECTED] 6/10/2003 9:02:07 PM Hi there, Here is the situation.. Say I have class A and class B 1-m I created the repository.xml Everything works fine when storing A to DB with a couple of B's Tx.lock(a, Transaction.WRITE); Tx.Commit Next step is to load a and add more B's and then save it again. I created the query. And all a and the related B's get loaded ok Now I add a couple more B's And store a Tx.lock(a, Transaction.WRITE); Also tried Tx.lock(a, Transaction.UPGRADE); But the new B's don't get inserted in DB. Any ideas Thanks Sam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1:m relation not updating
You have to lock the b elements too if you are using normal collections to hold the many-side of the association. If you were using DList as your collection class this won't be required. cheers, thomas Saman Ghodsian wrote: Hi there, Here is the situation.. Say I have class A and class B 1-m I created the repository.xml Everything works fine when storing A to DB with a couple of B's Tx.lock(a, Transaction.WRITE); Tx.Commit Next step is to load a and add more B's and then save it again. I created the query. And all a and the related B's get loaded ok Now I add a couple more B's And store a Tx.lock(a, Transaction.WRITE); Also tried Tx.lock(a, Transaction.UPGRADE); But the new B's don't get inserted in DB. Any ideas Thanks Sam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
