Inheritance: One Table
Hi,
I have I inheritance-problem. I want to map two classes to one table.
They are defined as followed:
class A {
int id;
protected String ojbConcreteClass;
// some attributes
}
class B extends A {
// some additional attributes
}
I created class-descriptors for each of the table:
class-descriptor class=A table=table
// field-descriptors for A inluding ojbConcreteClass
/class
and
class-descriptor class=B table=table extends=A
// additional field-descriptors for B
/class
So: When I try to store an instance of Type A everything is fine. But
when I try to store an instance of Type B OJB complains:
Caused by:
org.apache.ojb.broker.metadata.ClassNotPersistenceCapableException: OJB
needs at least one primary key attribute for class
objectsRealClass=class kos.wnetz.om.RelationHistoryEvent,
objectTopLevelClass=class kos.wnetz.om.RelationHistoryEvent
at org.apache.ojb.broker.Identity.checkForPrimaryKeys(Identity.java:245)
at org.apache.ojb.broker.Identity.init(Identity.java:121)
So I also tried to include the field-descriptors of the superclass in
the class-descriptor for class B. But then I get an even worse error:
Caused by: java.sql.SQLException: Parameter index out of range (8 7).
at
com.mysql.jdbc.PreparedStatement.setInternal(PreparedStatement.java:1940)
at com.mysql.jdbc.PreparedStatement.setString(PreparedStatement.java:1075)
at com.mysql.jdbc.PreparedStatement.setObject(PreparedStatement.java:766)
at com.mysql.jdbc.PreparedStatement.setObject(PreparedStatement.java:892)
at
org.apache.ojb.broker.platforms.PlatformDefaultImpl.setObjectForStatement(PlatformDefaultImpl.java:227)
at
org.apache.ojb.broker.platforms.PlatformMySQLImpl.setObjectForStatement(PlatformMySQLImpl.java:87)
at
org.apache.ojb.broker.accesslayer.StatementManager.bindInsert(StatementManager.java:449)
at
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeInsert(JdbcAccessImpl.java:193)
... 47 more
So obviously I am missing somthing. do you have any suggestions?
Tino
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inheritance: One Table
Tino Schöllhorn wrote:
Hi,
I have I inheritance-problem. I want to map two classes to one table.
They are defined as followed:
class A {
int id;
protected String ojbConcreteClass;
// some attributes
}
class B extends A {
// some additional attributes
}
I created class-descriptors for each of the table:
class-descriptor class=A table=table
// field-descriptors for A inluding ojbConcreteClass
/class
and
class-descriptor class=B table=table extends=A
// additional field-descriptors for B
/class
So: When I try to store an instance of Type A everything is fine. But
when I try to store an instance of Type B OJB complains:
Caused by:
org.apache.ojb.broker.metadata.ClassNotPersistenceCapableException: OJB
needs at least one primary key attribute for class
objectsRealClass=class kos.wnetz.om.RelationHistoryEvent,
objectTopLevelClass=class kos.wnetz.om.RelationHistoryEvent
at
org.apache.ojb.broker.Identity.checkForPrimaryKeys(Identity.java:245)
at org.apache.ojb.broker.Identity.init(Identity.java:121)
So I also tried to include the field-descriptors of the superclass in
the class-descriptor for class B. But then I get an even worse error:
Caused by: java.sql.SQLException: Parameter index out of range (8 7).
I don't know where this exception comes from, but in order to describe a
super-subtype relationship you should use something like:
class-descriptor class=A table=table
extent-class class-ref=B/
// field-descriptors for A inluding ojbConcreteClass
/class
and
class-descriptor class=B table=table
// field-descriptors for B including ojbConcreteClass
/class
The extent-class is inverse to the extends/implements in Java (i.e.
specified at the supertype), and also note that the class-descriptor for
B contains all attributes of A (there is no automatic 'inheritance' of
the descriptors in the repository.xml file) including the
ojbConcreteClass attribute.
Tom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Bug with OTM API and proxies ?
Hi Oleg
here are the informations.
First, the data before the test (I include only the ids, the tables are
quite long):
ID ID_DOSSIER
totoMon Jun 14 08:35:27 CEST 2004 2870475
totoWed Jun 09 17:05:30 CEST 2004 2870475
510183102 2870475
5870475 2870475
894125102 2870475
954125102 2870475
After the test.
ID ID_DOSSIER
totoMon Jun 14 08:56:17 CEST 2004 2870475
totoWed Jun 09 17:05:30 CEST 2004 2870475
510183102 2870475
5870475 2870475
894125102 2870475
954125102 2870475
The row with the id totoMon Jun 14 08:56:17 CEST 2004 has been added, but
the id totoMon Jun 14 08:35:27 CEST 2004 has been deleted.
Here is the test code used.
-
OTMKit kit = SimpleKit.getInstance();
OTMConnection conn = null;
Transaction tx = null;
DossierImpl dossier = null;
try {
conn =
kit.acquireConnection(PersistenceBrokerFactory.getDefaultKey());
tx = kit.getTransaction(conn);
tx.begin();
// retrieve DossierImpl
Criteria crit = new Criteria();
crit.addEqualTo(id, 2870475);
Query q = new QueryByCriteria(DossierImpl.class, crit);
Iterator dossiers = conn.getIteratorByQuery(q);
if (dossiers.hasNext()) dossier = (DossierImpl) dossiers.next();
// add new FeuilleCalculRemboursement
FeuilleCalcul feuille = new FeuilleCalculRemboursementImpl();
feuille.setId(toto + new java.util.Date());
dossier.addFeuilleCalcul(feuille);
tx.commit();
} finally {
if (conn != null) conn.close();
}
-
My two objects of type DossierImpl and FeuilleCalculRemboursement are POJOs
and the method addFeuilleCalcul(feuille) just performs add(Object) on a
java.util.Collection.
This is my repository_user.xml :
class-descriptor
class=ch.admin.ofit.prestations.bm.commun.dossier.DossierImpl
table=TPUDOSSIER
field-descriptor
name=id
column=ID
jdbc-type=VARCHAR
primarykey=true
autoincrement=false
/
field-descriptor
name=appliDefinition
column=APPLI_DEF
jdbc-type=VARCHAR
/
field-descriptor
name=referenceExterne
column=REF_EXT
jdbc-type=VARCHAR
/
field-descriptor
name=langue
column=LANGUE
jdbc-type=CHAR
/
field-descriptor
name=convention
column=CONVENTION
jdbc-type=VARCHAR
/
collection-descriptor
name=feuillesCalcul
element-class-ref=
ch.admin.ofit.prestations.bm.commun.feuillecalcul.AbstractFeuilleCalculImpl
auto-update=object
inverse-foreignkey field-ref=idDossier/
/collection-descriptor
/class-descriptor
class-descriptor
class=
ch.admin.ofit.prestations.bm.commun.feuillecalcul.AbstractFeuilleCalculImpl
extent-class class-ref=
ch.admin.ofit.prestations.bm.rente.feuillecalcul.FeuilleCalculRemboursementImpl
/
extent-class class-ref=
ch.admin.ofit.prestations.bm.rente.feuillecalcul.FeuilleCalculTransfertImpl
/
/class-descriptor
class-descriptor
class=
ch.admin.ofit.prestations.bm.rente.feuillecalcul.FeuilleCalculRemboursementImpl
proxy=dynamic
table=TPRFCRMBT
field-descriptor
name=id
column=ID
jdbc-type=VARCHAR
primarykey=true
autoincrement=false
/
field-descriptor
name=dateCreation
column=DATE_CREATION
conversion=
ch.admin.ofit.ojb.conversion.Date2SqlVarcharFiedConversion
jdbc-type=CHAR
/
field-descriptor
name=exploitee
column=BOOL_EXPLOITEE
conversion=
ch.admin.ofit.ojb.conversion.Boolean2SqlCharFiedConversion
jdbc-type=CHAR
/
field-descriptor
name=type
column=UCODE_TYPE
jdbc-type=VARCHAR
/
field-descriptor
name=idDossier
jdbc-type=VARCHAR
column=ID_DOSSIER
access=anonymous
/
field-descriptor
name=droitApplique
column=UCODE_REVISION
Re: Inheritance: One Table
Tino Schöllhorn wrote: thanks now it works. But why do I have to map the attributes of the superclass in the subclass again? Is this intended or is the inheritance of descriptors a not yet enhancement? Yes, this is by intention because you don't necessarily want to have all persistent fields of the superclass in the subclass. For the 1.1 we might make this a bit more comfortable by adding a flag to the class descriptor that defines whether the the features shall be inherited (with auto inheritance the default). Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inheritance: One Table
Hi,
unfortunately I still have one problem:
I use a xml-parser to pre-validate the repository.xml-file. This Parser
now complains that field-descriptors cannot be used when using extent. I
checked that with the DTD and I think it is correct:
!ELEMENT class-descriptor
((documentation?, extent-class+, attribute*) |
(documentation?, object-cache?, extent-class*, field-descriptor+,
reference-descriptor*, collection-descriptor*,
index-descriptor*, attribute*,
insert-procedure?, update-procedure?, delete-procedure?))
But the thing is: OJB works correctly. So what do I do now? Should I
ignore this warning? Or do I have to create a not-persistent abstract
superclass?
Tino
Thomas Dudziak wrote:
Tino Schöllhorn wrote:
Hi,
I have I inheritance-problem. I want to map two classes to one table.
They are defined as followed:
class A {
int id;
protected String ojbConcreteClass;
// some attributes }
class B extends A {
// some additional attributes
}
I created class-descriptors for each of the table:
class-descriptor class=A table=table
// field-descriptors for A inluding ojbConcreteClass
/class
and
class-descriptor class=B table=table extends=A
// additional field-descriptors for B
/class
So: When I try to store an instance of Type A everything is fine. But
when I try to store an instance of Type B OJB complains:
Caused by:
org.apache.ojb.broker.metadata.ClassNotPersistenceCapableException:
OJB needs at least one primary key attribute for class
objectsRealClass=class kos.wnetz.om.RelationHistoryEvent,
objectTopLevelClass=class kos.wnetz.om.RelationHistoryEvent
at
org.apache.ojb.broker.Identity.checkForPrimaryKeys(Identity.java:245)
at org.apache.ojb.broker.Identity.init(Identity.java:121)
So I also tried to include the field-descriptors of the superclass in
the class-descriptor for class B. But then I get an even worse error:
Caused by: java.sql.SQLException: Parameter index out of range (8 7).
I don't know where this exception comes from, but in order to describe a
super-subtype relationship you should use something like:
class-descriptor class=A table=table
extent-class class-ref=B/
// field-descriptors for A inluding ojbConcreteClass
/class
and
class-descriptor class=B table=table
// field-descriptors for B including ojbConcreteClass
/class
The extent-class is inverse to the extends/implements in Java (i.e.
specified at the supertype), and also note that the class-descriptor for
B contains all attributes of A (there is no automatic 'inheritance' of
the descriptors in the repository.xml file) including the
ojbConcreteClass attribute.
Tom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inheritance: One Table
Tino Schöllhorn wrote: Hi, unfortunately I still have one problem: I use a xml-parser to pre-validate the repository.xml-file. This Parser now complains that field-descriptors cannot be used when using extent. I checked that with the DTD and I think it is correct: !ELEMENT class-descriptor ((documentation?, extent-class+, attribute*) | (documentation?, object-cache?, extent-class*, field-descriptor+, reference-descriptor*, collection-descriptor*, index-descriptor*, attribute*, insert-procedure?, update-procedure?, delete-procedure?)) But the thing is: OJB works correctly. So what do I do now? Should I ignore this warning? Or do I have to create a not-persistent abstract superclass? I think, your XML parser is in error here (it probably matches the first branch as soon as it sees the extent-class) because extent-class + field-descriptor is definitely allowed (second branch). If I'm not mistaken, OJB also uses the XML parser with validation turned on, so you should not have to validate the repository.xml file, anyway. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Launching a statement SQL fom OJB
Hi! Suppose I've to do something in the DB launching directly an SQL statement, bypassing OJB how can I do it? And how to prevent problems with the object cache of OJB? ie: if a launch UPDATE costs_table SET cost = cost + 10, but some record has already been loaded in memory by OJB...how can I get them updated? (same problems for inserts and updates...) Thanks and bye! Paolo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: My proxies do not make late binding
Yes, I am using ODMG.
I have downloaded RC7 this morning and tried again. The collection proxy
works fine, but I still have problems with the reference proxies. Here is
the code snippet I am executing :
public void testModificationDirect() {
String idDossier = test.ojb.1000;
try {
Implementation impl = OJB.getInstance();
Database db = impl.newDatabase();
db.open(TESTDEV, Database.OPEN_READ_WRITE);
Transaction tx = impl.newTransaction();
tx.begin();
OQLQuery q = impl.newOQLQuery();
q.create(select dossiers from + DossierImpl.class
.getName() + where id = $1);
q.bind(idDossier);
DList results = (DList) q.execute();
Dossier d = (DossierImpl) results.iterator().next();
assertNotNull(d);
tx.lock(d,Transaction.WRITE);
for (Iterator iter = d.getPrestations().iterator();
iter.hasNext();) {
Prestation prest = (Prestation) iter.next();
prest.setMontant(prest.getMontant().add(new
BigDecimal(100)));
}
tx.commit();
} catch (Exception e) {
e.printStackTrace();
fail();
}
}
The object of type Dossier is retrieved correctly. It has a real
RemovalAwareCollection of non materialized proxies. But then arise the
problems :
- at the first method invocation on one of the proxies
(prest.setMontant(...)) all the proxies of the collection are materialized,
not only the current one;
- at the commit, the real objects are not stored in the database. The java
object are updated, but OJB does not realise that they were and does not
report the new state in the database. If I try without proxies, the update
is made. If I put a proxy on the collection, everithig works fine too.
I don't join other information for now, just ask me what you need to
dignosticate the problem.
Stefano
|-+-
| | Brian McCallister |
| | [EMAIL PROTECTED]|
| | ompany.com |
| | |
| | 11.06.2004 17:57 |
| | Veuillez répondre à |
| | OJB Users List |
| | |
|-+-
--|
|
|
|Pour : OJB Users List [EMAIL PROTECTED]
|
|cc :
|
|Objet : Re: Réf. : Re: My proxies do not make late binding
|
--|
Assuming you are using ODMG...
The problem was with the implicit locking mechanism in the ODMG
implementation. It was not properly detecting collection proxies so it
would iterate over the collection (loading it) and lock every object
before even returning from the OQLQuery#execute() call.
I have fixed this in cvs so that it will register itself as a
materialization listener on any implementation of CollectionProxy which
has not yet been loaded, and only bind the contents of the collection
to the transaction if the collection is loaded during the transaction.
If you are using the default proxies, you should be fine if you pull
the version from CVS, or use the release coming up (if Thomas D.
retracts his vote to go to 1.0 final instead of an rc ;-) this weekend.
-Brian
On Jun 11, 2004, at 11:45 AM, Thomas Dudziak wrote:
On Fri, 11 Jun 2004 [EMAIL PROTECTED] wrote:
I looked at the URL you sent me, but I dont know enough the internals
of
OJB to understand the message. I went a little further : I tried to
get the
Persistence Broker from the transaction and to execute a good old OJB
QueryByCriteria : the late binding works.
Yup, the problem is with ODMG, not with the PB Api.
Besides that, I am not sure that the problem is only with the
collection
proxy. I have also tried with single-object dynamic proxies and the
same
result (returns already materialized proxies).
They should work (might depend on how old the OJB version is that
you're using though). As I said, please try the latest from CVS.
Wish you a happy week-end
Same for you :-)
Tom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
Re: My proxies do not make late binding
I was just poking around ODMG to fix the collection proxy thing, can
nose around about regular references.
I probably won't get a chance to look at it until tomorrow night at the
earliest, so if anyone else has a moment sooner... =)
Thank you for finding the problems!
-Brian
On Jun 14, 2004, at 7:36 AM, [EMAIL PROTECTED] wrote:
Yes, I am using ODMG.
I have downloaded RC7 this morning and tried again. The collection
proxy
works fine, but I still have problems with the reference proxies. Here
is
the code snippet I am executing :
public void testModificationDirect() {
String idDossier = test.ojb.1000;
try {
Implementation impl = OJB.getInstance();
Database db = impl.newDatabase();
db.open(TESTDEV, Database.OPEN_READ_WRITE);
Transaction tx = impl.newTransaction();
tx.begin();
OQLQuery q = impl.newOQLQuery();
q.create(select dossiers from + DossierImpl.class
.getName() + where id = $1);
q.bind(idDossier);
DList results = (DList) q.execute();
Dossier d = (DossierImpl) results.iterator().next();
assertNotNull(d);
tx.lock(d,Transaction.WRITE);
for (Iterator iter = d.getPrestations().iterator();
iter.hasNext();) {
Prestation prest = (Prestation) iter.next();
prest.setMontant(prest.getMontant().add(new
BigDecimal(100)));
}
tx.commit();
} catch (Exception e) {
e.printStackTrace();
fail();
}
}
The object of type Dossier is retrieved correctly. It has a real
RemovalAwareCollection of non materialized proxies. But then arise the
problems :
- at the first method invocation on one of the proxies
(prest.setMontant(...)) all the proxies of the collection are
materialized,
not only the current one;
- at the commit, the real objects are not stored in the database. The
java
object are updated, but OJB does not realise that they were and does
not
report the new state in the database. If I try without proxies, the
update
is made. If I put a proxy on the collection, everithig works fine too.
I don't join other information for now, just ask me what you need to
dignosticate the problem.
Stefano
|-+-
| | Brian McCallister |
| | [EMAIL PROTECTED]|
| | ompany.com |
| | |
| | 11.06.2004 17:57 |
| | Veuillez répondre à |
| | OJB Users List |
| | |
|-+-
--
|
|
|
|Pour : OJB Users List [EMAIL PROTECTED]
|
|cc :
|
|Objet : Re: Réf. : Re: My proxies do not make late binding
|
--
|
Assuming you are using ODMG...
The problem was with the implicit locking mechanism in the ODMG
implementation. It was not properly detecting collection proxies so it
would iterate over the collection (loading it) and lock every object
before even returning from the OQLQuery#execute() call.
I have fixed this in cvs so that it will register itself as a
materialization listener on any implementation of CollectionProxy which
has not yet been loaded, and only bind the contents of the collection
to the transaction if the collection is loaded during the transaction.
If you are using the default proxies, you should be fine if you pull
the version from CVS, or use the release coming up (if Thomas D.
retracts his vote to go to 1.0 final instead of an rc ;-) this weekend.
-Brian
On Jun 11, 2004, at 11:45 AM, Thomas Dudziak wrote:
On Fri, 11 Jun 2004 [EMAIL PROTECTED] wrote:
I looked at the URL you sent me, but I dont know enough the internals
of
OJB to understand the message. I went a little further : I tried to
get the
Persistence Broker from the transaction and to execute a good old OJB
QueryByCriteria : the late binding works.
Yup, the problem is with ODMG, not with the PB Api.
Besides that, I am not sure that the problem is only with the
collection
proxy. I have also tried with single-object dynamic proxies and the
same
result (returns already
[ANN] OJB 1.0rc7 Released
The OJB team would like to announce the release of Apache Object/Relational Bridge (OJB) 1.0rc7. This release will hopefully be the final release candidate before version 1.0. If no major problems are discovered, OJB 1.0 will be released in one week. DOWNLOADS http://db.apache.org/builds/ojb/ CHANGES: - New Apache Forrest generated web site. - OJB.properties file has changed, don't forget to replace on update! One new property to set in managed environments. - Logging settings have moved to separate OJB-logging.properties file - Logging initialization is now decoupled form OJB initialization; this is described in the new reference guide for logging - It is no longer necessary to provide an empty repository.xml file when starting without repository and connection descriptors - rename/move internal package org.apache.ojb.odmg.transaction to org.apache.ojb.broker.transaction.tm In managed environments each (top-level) API use transaction manager access, thus the TM related classes are moved to the PB kernel and OJB.properties entries change. - Base class for ODMG api access within non- or managed environments is now org.apache.ojb.odmg.OJB. The used org.odmg.Implementation interface implementation is specified in OJB.properties. - ConnectionManager is more strict on CM.releaseConnection() method calls. Now an exception is thrown when CM is in a local transaction status when try to release the connection. The local tx status of ConnectionManager and PersistenceBroker implementation is now decoupled, useful in managed environments allows to close the connection without change the PB tx-state. - the indirection handler (for reference proxies), and the list and set proxy classes can now be configured in the OJB.properties file - new CollectionProxy interface introduced to allow the ODMG api to make use of alternate collection proxy implementations. KNOWN ISSUES: - odmg-api: It is not possible to exchange objects in 1:n references. - odmg-api: Creation of m:n relation only works when objects created step by step (or use PB-api as workaround), persist a whole object graph doesn't work. On delete of collection objects from a m:n relation objects will be deleted from the indirection table and (unexpected behaviour) from the referenced table too. - A count on ReportQueries containing groupBy does not deliver a correct result. - Batch handling doesn't work properly with optimistic locking. - ReportQueries should not be used with columns referencing Classes with extents. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Deletion and Cache
Hi, I think this topic has been discussed before. But I am not sure what the current status is: I have two classes A and B. A has a Collection of Bs. Now if I delete a B object which is part of a Collection of an A object the B object is correctly deleted in the database and is also removed from the cache, BUT the A-Object still references the now deleted B-Object in its collection. From the disussion I am not sure if this is a bug (I am using rc6) or if I am just using the wrong Collection class (I am using ManageableArrayList). With regards Tino - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cascading anonymous keys
Armin,
I have tried my code with rc7 and I still have the problem I described.
Looking at the test case you have written, it seems to produce the results
I would like. That is, your code does not return null objects for objects
that should be retrieved via anonymous foreign keys contained within nested
objects.
The only major difference I have seen between your test case and my code
thus far is that you have a reference to a Person within the PersonDetail.
public static class PersonDetail implements PersonDetailIF
{
Integer id;
String profile;
Person person; // - I don't have this
reference
GenderIF gender;
...
I tried adding a reference like you have but ended up with the same results
that I had without such a reference.
My code looks very much like your test case, but I still get nulls on my
nested objects if I use anonymous keys and turn proxies off.
While I think you have shown that the problems must be with my code
somewhere, I'm certainly baffled as to what might be wrong.
I am using PersistentFieldIntrospectorImpl and most of my properties are
private, do you suppose that would cause a problem on nested objects?
Thank you very much for looking into this for me.
Brian
At 08:58 AM 06/12/2004, Armin Waibel wrote:
Hi Brian,
I tried to reproduce your problem (with latest from CVS) without success.
A new test case was added to test suite ([db-ojb]/src/test/org/...) called
PrimaryKeyForeignKeyTest.java, the mapping is declared in
repository_junit_reference.
Please have a look at this test, does it reproduce your problem?
regards,
Armin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] OJB 1.0rc7 Released
I'm wondering if the listed KNOWN ISSUES will be resolved for 1.0? It sounds like not, and at least one of them worries me. Brian - odmg-api: It is not possible to exchange objects in 1:n Brian references. I'm not sure what this means. Is it a new problem? Brian - odmg-api: Creation of m:n relation only works when Brian objects created Brian step by step (or use PB-api as workaround), persist a whole Brian object graph doesn't work. On delete of collection objects Brian from a m:n relation objects will be deleted from the Brian indirection table and (unexpected behaviour) from the Brian referenced table too. This sounds very big and also sounds new to me. I've been persisting object graphs in ODMG without problems. Also unsure about the deletion piece: Does this mean that auto-delete=link doesn't work with ODMG any more (it's been working ok in RC6)? thanks, -- Steve Clark Technology Applications Team Natural Resources Research Center/USGS [EMAIL PROTECTED] (970)226-9291 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] OJB 1.0rc7 Released
Hi Steve, Steve Clark wrote: I'm wondering if the listed KNOWN ISSUES will be resolved for 1.0? We try to list all unsolved major issues for 1.0 (we are open source, thus there is no reason for keep quiet about known issue). We will try to fix these problems ASAP in a 1.0x release. It sounds like not, and at least one of them worries me. Brian - odmg-api: It is not possible to exchange objects in 1:n Brian references. I'm not sure what this means. Is it a new problem? No, sorry my bad english. Will try to explain. Say A has a 1:n relation to B. The status of the locked referenced objects (B's) of A currently noticed only by the size of the collection. If you now remove one B object and add another already existing (and locked) B object the size of the referenced collection doesn't change and the A object doesn't get dirty and the FK in B wasn't changed. Only in this case the bug arise. Brian - odmg-api: Creation of m:n relation only works when Brian objects created Brian step by step (or use PB-api as workaround), persist a whole Brian object graph doesn't work. On delete of collection objects Brian from a m:n relation objects will be deleted from the Brian indirection table and (unexpected behaviour) from the Brian referenced table too. This sounds very big and also sounds new to me. I've been persisting object graphs in ODMG without problems. I don't think it's new, we only don't have an test case for this problem till now (this issue is only based on m:n relations). Also unsure about the deletion piece: Does this mean that auto-delete=link doesn't work with ODMG any more (it's been working ok in RC6)? hmm, at all times the top-level api need the default values for auto-xxx settings: auto-retrieve true auto-update false auto-delete false But except for auto-delete on 1:1 relation, 'false' is equals with 'link'. regards, Armin thanks, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] OJB 1.0rc7 Released
Brian - odmg-api: Creation of m:n relation only works when Brian objects created step by step (or use PB-api as workaround), Brian persist a whole object graph doesn't work. On delete of Brian collection objects from a m:n relation objects will be Brian deleted from the indirection table and (unexpected Brian behaviour) from the referenced table too. me Also unsure about the deletion piece: Does this mean that me auto-delete=link doesn't work with ODMG any more (it's been me working ok in RC6)? Armin hmm, at all times the top-level api need the default values Armin for auto-xxx settings: Armin auto-retrieve true Armin auto-update false Armin auto-delete false Armin But except for auto-delete on 1:1 relation, 'false' is Armin equals with 'link'. Oops. I shouldn't have brought in auto-delete. It sounds from the release notes like there's a new behavior where removing an object from an m:n relation removes the object from the db, as well. Is this only with RemovalAwareCollection (in which case I think it's expected?), or is this with all collection classes (in which case I think it's a new behavior and very seriously broken)? thanks, -- Steve Clark Technology Applications Team Natural Resources Research Center/USGS [EMAIL PROTECTED] (970)226-9291 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SequenceManagerStoredProcedureImpl and DB2
Hi all As many knowns sequences are not implemented by all db provider. Special mention to DB2 AS400 in my jobs. I was looking to SequenceManagerStoredProcedureImpl sequence manager solution. Quite pleasant by not implemented within PlatformDb2Impl just for M$SQLServer ... I'd like to implement DB2 AS400 method... ideas, comment, hints ... Thanks OJB rocks ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inheritance: One Table
Hi Tino,
Have you an unique Id in class A? Try this example (I have followed the
OJB Tutorial ):
class-descriptor class=ojb.test.A table=T_AB
isolation-level=read-uncommitted accept-locks=true refresh=true
extent-class class-ref=ojb.test.B /
field-descriptor name=oid column=oid jdbc-type=INTEGER
primarykey=true autoincrement=true/
field-descriptor name=attA column=attA
jdbc-type=VARCHAR/
field-descriptor name=ojbConcreteClass column=CLASS_NAME
jdbc-type=VARCHAR/
/class-descriptor
class-descriptor class=ojb.test.B table=T_AB
isolation-level=read-uncommitted accept-locks=true refresh=true
field-descriptor name=oid column=oid jdbc-type=INTEGER
primarykey=true autoincrement=true/
field-descriptor name=attA column=attA
jdbc-type=VARCHAR/
field-descriptor name=ojbConcreteClass column=CLASS_NAME
jdbc-type=VARCHAR/
field-descriptor name=attB column=attB
jdbc-type=VARCHAR/
/class-descriptor
Below the ORACLE ddl ( modify database type for MySql):
create table T_AB (
oidINTEGER NOT NULL,
attAVARCHAR2 ( 48 ) NULL,
attBVARCHAR2 ( 48 ) NULL,
CLASS_NAME VARCHAR ( 48 ) NULL,
constraint PK_T_AB PRIMARY KEY (oid)
)
I hope that will help you,
Gildas
- Original Message -
From: Tino Schöllhorn mailto:[EMAIL PROTECTED]
[EMAIL PROTECTED]
To: mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]
Sent: Monday, June 14, 2004 8:46 AM
Subject: Inheritance: One Table
Hi,
I have I inheritance-problem. I want to map two classes to one table.
They are defined as followed:
class A {
int id;
protected String ojbConcreteClass;
// some attributes
}
class B extends A {
// some additional attributes
}
I created class-descriptors for each of the table:
class-descriptor class=A table=table
// field-descriptors for A inluding ojbConcreteClass
/class
and
class-descriptor class=B table=table extends=A
// additional field-descriptors for B
/class
So: When I try to store an instance of Type A everything is fine. But
when I try to store an instance of Type B OJB complains:
Caused by:
org.apache.ojb.broker.metadata.ClassNotPersistenceCapableException:
OJB
needs at least one primary key attribute for class
objectsRealClass=class kos.wnetz.om.RelationHistoryEvent,
objectTopLevelClass=class kos.wnetz.om.RelationHistoryEvent
at
org.apache.ojb.broker.Identity.checkForPrimaryKeys(Identity.java:245)
at org.apache.ojb.broker.Identity.init(Identity.java:121)
So I also tried to include the field-descriptors of the superclass in
the class-descriptor for class B. But then I get an even worse error:
Caused by: java.sql.SQLException: Parameter index out of range (8
7).
at
com.mysql.jdbc.PreparedStatement.setInternal(PreparedStatement.java:1940
)
at
com.mysql.jdbc.PreparedStatement.setString(PreparedStatement.java:1075)
at
com.mysql.jdbc.PreparedStatement.setObject(PreparedStatement.java:766)
at
com.mysql.jdbc.PreparedStatement.setObject(PreparedStatement.java:892)
at
org.apache.ojb.broker.platforms.PlatformDefaultImpl.setObjectForStatemen
t(PlatformDefaultImpl.java:227)
at
org.apache.ojb.broker.platforms.PlatformMySQLImpl.setObjectForStatement(
PlatformMySQLImpl.java:87)
at
org.apache.ojb.broker.accesslayer.StatementManager.bindInsert(StatementM
anager.java:449)
at
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeInsert(JdbcAcces
sImpl.java:193)
... 47 more
So obviously I am missing somthing. do you have any suggestions?
Tino
-
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[EMAIL PROTECTED]
a lot of delete statements on insert m:n rc7
Hello,
I have a simple unit test class :
public static String id;
public AppointmentDelegateTest(String arg0)
throws Exception
{
super(arg0);
Appointment appointment = new Appointment();
User user = new User();
appointment.setUser(user);
appointment.setCreationDate( new java.util.Date() );
appointment.put();
GenericDelegate.getInstance().clearCache();
id = appointment.getId().toString();
}
PersistenceBroker broker ;
protected void setUp() throws Exception
{
super.setUp();
try{
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
}
catch (PBFactoryException e)
{
}
protected void tearDown() throws Exception
{
super.tearDown();
broker.close();
}
public void testGetAppointment()
throws Exception
{
Criteria criteria = new Criteria();
criteria.addEqualTo(id, new Integer(id));
Query q = QueryFactory.newQuery( Appointment.class , criteria);
Appointment appointment = (Appointment) broker.getObjectByQuery(q);
assertNotNull( appointment );
}
---
the sql debug output =
-
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:INSERT INTO Appointment
(longdescription,noofattachement,shortdescription,userid,totime,fromtime,id,
creationdate,location) VALUES (?,?,?,?,?,?,?,?,?)
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Contact WHERE appointmentId=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Attachement WHERE appointmentid=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Contact WHERE appointmentId=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Attachement WHERE appointmentid=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Contact WHERE appointmentId=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Attachement WHERE appointmentid=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Contact WHERE appointmentId=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Attachement WHERE appointmentid=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Contact WHERE appointmentId=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Attachement WHERE appointmentid=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Contact WHERE appointmentId=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Attachement WHERE appointmentid=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Contact WHERE appointmentId=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Attachement WHERE appointmentid=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Contact WHERE appointmentId=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Attachement WHERE appointmentid=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Contact WHERE appointmentId=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Attachement WHERE appointmentid=?
...[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl]
DEBUG: SQL:SELECT
A0.userid,A0.longdescription,A0.totime,A0.fromtime,A0.location,A0.noofattach
ement,A0.creationdate,A0.id,A0.shortdescription FROM Appointment A0 WHERE
A0.id = ?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:SELECT password,logname,usercontactid,id FROM User WHERE id = ?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
Result of getTableAlias(): null
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
Result of getTableAlias(): null
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
Result of getTableAlias(): null
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
Result of getTableAlias(): null
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:SELECT
A0.gender,A0.phone,A0.mailheader,A0.title,A0.type,A0.function,A0.privat,A0.m
ailfooter,A0.id,A0.mobilephone,A0.companyid,A0.lastname,A0.userid,A0.middlen
ame,A0.searchname,A0.firstname,A0.online,A0.dateofbirth,A0.initials,A0.email
,A0.creationdate FROM Contact A0,Appointment2Contact WHERE
(Appointment2Contact.appointmentId = ?) AND Appointment2Contact.contactId =
A0.id
Re: a lot of delete statements on insert m:n rc7
there i am again , setting collection-class=managableList solved all the
deleteting so forget about my question please. I still see Result of
getTableAlias(): null though , what does it mean?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:INSERT INTO Appointment
(longdescription,noofattachement,shortdescription,userid,totime,fromtime,id,
creationdate,location) VALUES (?,?,?,?,?,?,?,?,?)
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Contact WHERE appointmentId=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Attachement WHERE appointmentid=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:SELECT
A0.userid,A0.longdescription,A0.totime,A0.fromtime,A0.location,A0.noofattach
ement,A0.creationdate,A0.id,A0.shortdescription FROM Appointment A0 WHERE
A0.id = ?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:SELECT password,logname,usercontactid,id FROM User WHERE id = ?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
Result of getTableAlias(): null
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
Result of getTableAlias(): null
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
Result of getTableAlias(): null
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
Result of getTableAlias(): null
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:SELECT
A0.gender,A0.phone,A0.mailheader,A0.title,A0.type,A0.function,A0.privat,A0.m
ailfooter,A0.id,A0.mobilephone,A0.companyid,A0.lastname,A0.userid,A0.middlen
ame,A0.searchname,A0.firstname,A0.online,A0.dateofbirth,A0.initials,A0.email
,A0.creationdate FROM Contact A0,Appointment2Contact WHERE
(Appointment2Contact.appointmentId = ?) AND Appointment2Contact.contactId =
A0.id
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
Result of getTableAlias(): null
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
Result of getTableAlias(): null
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
Result of getTableAlias(): null
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
Result of getTableAlias(): null
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:SELECT A0.originalfilename,A0.filename,A0.id FROM Attachement
A0,Appointment2Attachement WHERE (Appointment2Attachement.appointmentid = ?)
AND Appointment2Attachement.attachementId = A0.id
Time: 0,591
OK (1 test)
gr,
Dennis
- Original Message -
From: dennis bekkering [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Sent: Tuesday, June 15, 2004 4:05 AM
Subject: a lot of delete statements on insert m:n rc7
Hello,
I have a simple unit test class :
public static String id;
public AppointmentDelegateTest(String arg0)
throws Exception
{
super(arg0);
Appointment appointment = new Appointment();
User user = new User();
appointment.setUser(user);
appointment.setCreationDate( new java.util.Date() );
appointment.put();
GenericDelegate.getInstance().clearCache();
id = appointment.getId().toString();
}
PersistenceBroker broker ;
protected void setUp() throws Exception
{
super.setUp();
try{
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
}
catch (PBFactoryException e)
{
}
protected void tearDown() throws Exception
{
super.tearDown();
broker.close();
}
public void testGetAppointment()
throws Exception
{
Criteria criteria = new Criteria();
criteria.addEqualTo(id, new Integer(id));
Query q = QueryFactory.newQuery( Appointment.class , criteria);
Appointment appointment = (Appointment) broker.getObjectByQuery(q);
assertNotNull( appointment );
}
---
the sql debug output =
-
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:INSERT INTO Appointment
(longdescription,noofattachement,shortdescription,userid,totime,fromtime,id,
creationdate,location) VALUES (?,?,?,?,?,?,?,?,?)
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Contact WHERE appointmentId=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Attachement WHERE appointmentid=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Contact WHERE appointmentId=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Attachement WHERE appointmentid=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Contact WHERE appointmentId=?
[org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:
SQL:DELETE FROM Appointment2Attachement
