Re: Descriptor changes documented?
Never mind, these actually were duped but for some reason it wasn't
failing before. Sorry for spamming the list.
-warner
On 10/27/05, Warner Onstine <[EMAIL PROTECTED]> wrote:
> So I noticed that the descriptor version went from 1.0 to 1.1, I'm
> also getting several of these errors now:
> Replace already registered class
> 'org.kuali.module.chart.bo.RestrictedStatus' with descriptor
> [EMAIL PROTECTED]
> classNameOfObject=org.kuali.module.chart.bo.RestrictedStatus
> tableName=CA_RESTRICT_STAT_T
> schema=
> isMappedToTable=true
> extendClassNames=[]
> special ObjectCache=
> fields={}
> ]
> java.lang.Exception: Warn: New class-descriptor added (without
> removing the old one first) for:
> org.kuali.module.chart.bo.RestrictedStatus
> at
> org.apache.ojb.broker.metadata.DescriptorRepository.put(DescriptorRepository.java:496)
> at
> org.apache.ojb.broker.metadata.RepositoryXmlHandler.startElement(RepositoryXmlHandler.java:332)
>
> This is happening with more than one class so that leads me to believe
> that something has changed that I'll need to account for now.
>
> Thanks!
>
> -warner
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Descriptor changes documented?
So I noticed that the descriptor version went from 1.0 to 1.1, I'm
also getting several of these errors now:
Replace already registered class
'org.kuali.module.chart.bo.RestrictedStatus' with descriptor
[EMAIL PROTECTED]
classNameOfObject=org.kuali.module.chart.bo.RestrictedStatus
tableName=CA_RESTRICT_STAT_T
schema=
isMappedToTable=true
extendClassNames=[]
special ObjectCache=
fields={}
]
java.lang.Exception: Warn: New class-descriptor added (without
removing the old one first) for:
org.kuali.module.chart.bo.RestrictedStatus
at
org.apache.ojb.broker.metadata.DescriptorRepository.put(DescriptorRepository.java:496)
at
org.apache.ojb.broker.metadata.RepositoryXmlHandler.startElement(RepositoryXmlHandler.java:332)
This is happening with more than one class so that leads me to believe
that something has changed that I'll need to account for now.
Thanks!
-warner
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: MS Access
On 10/27/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Has anybody created a test database using Microsoft Access? When I run > "ant prepare-testdb" with MySQL, it works fine, but when I switch to > MSAccess, it gets this error: > C:\Java\db-ojb-1.0.3\ojb-blank\src\schema\build-torque.xml:300: > Exception thrown by 'generator.parse'. > For more information consult the velocity log, or invoke ant with the > -debug flag. You might want to check the Torque mailing list archives on what database type you should use if it supports Access at all. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
MS Access
OK, database gurus, Has anybody created a test database using Microsoft Access? When I run "ant prepare-testdb" with MySQL, it works fine, but when I switch to MSAccess, it gets this error: C:\Java\db-ojb-1.0.3\ojb-blank\src\schema\build-torque.xml:300: Exception thrown by 'generator.parse'. For more information consult the velocity log, or invoke ant with the -debug flag. When I use the ant -debug flag, I get this: Caused by: org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'sql/db-init/msaccess/createdb.vm' When I look in the Velocity log, it shows all the other .vm files being loaded (except VM_global_library.vm, but that always happens). Since I've always had trouble creating MsAccess databases with SQL, I created the database manually and commented out the create_db.sql step in the build.xml file and it got past it. It generates the SQL statements and executes them, but the following statements fail. From the pattern, it looks like MsAccess doesn't like "DECIMAL" "BIGINT" "BLOB" or "CLOB". What I don't know is what to substitute for these four data types. Would one of you nice folks take please tell me what it wants? I'll just execute them manually. I really don't want to fix Torque or Velocity or whatever caused it. Thanks, Jean [torque-sql-exec] Failed to execute: CREATE TABLE BLOB_TEST ( ID integer, BLOB_VALUE_, CLOB_VALUE_, PRIMARY KEY(ID) ) [torque-sql-exec] Failed to execute: CREATE TABLE SM_KEY ( INT_KEY integer, NAME VARCHAR (250), STRING_KEY VARCHAR (250), LONG_KEY BIGINT, INTEGER_KEY integer, PRIMARY KEY(INT_KEY) ) [torque-sql-exec] Failed to execute: CREATE TABLE EJB_ARTICLE ( ARTICLE_ID integer, NAME VARCHAR (80), PRICE DECIMAL (15,2), DESCRIPTION VARCHAR (255), CATEGORY_ID integer, PRIMARY KEY(ARTICLE_ID) ) [torque-sql-exec] Failed to execute: CREATE TABLE FIELD_CONVERSION_NODE ( NODE_ID DECIMAL (15,0), NODE_STATE integer, PARENT_UID DECIMAL (15,0), PRIMARY KEY(NODE_ID,NODE_STATE) ) [torque-sql-exec] Failed to execute: CREATE TABLE FIELD_CONVERSION_NODE_NOINC ( NODE_ID DECIMAL (15,0), PRIMARY KEY(NODE_ID) ) [torque-sql-exec] Failed to execute: CREATE TABLE NUMBER_ACCURACY_TEST ( OBJ_ID integer, SCALE_TWO DECIMAL (15,6), SCALE_FOUR DECIMAL (15,6), PRIMARY KEY(OBJ_ID) ) [torque-sql-exec] Failed to execute: CREATE TABLE BATCH_MAIN_OBJ ( OBJ_ID BIGINT, NAME VARCHAR (100), PRIMARY KEY(OBJ_ID) ) [torque-sql-exec] Failed to execute: CREATE TABLE BATCH_SUB_OBJ ( OBJ_ID BIGINT, FK_MAIN_ID BIGINT, NAME VARCHAR (100), PRIMARY KEY(OBJ_ID) ) [torque-sql-exec] Failed to execute: CREATE TABLE READONLY_TEST ( OBJ_ID DECIMAL (15,0), NAME VARCHAR (150), RO_STRING VARCHAR (150), RO_LONG DECIMAL (15,0), PRIMARY KEY(OBJ_ID) ) [torque-sql-exec] Failed to execute: CREATE TABLE NESTED_FIELDS_TAB ( OBJ_ID DECIMAL (15,0), NAME VARCHAR (150), NESTED_VALUE VARCHAR (150), NESTED_DESCRIPTION VARCHAR (150), PRIMARY KEY(OBJ_ID) ) [torque-sql-exec] Failed to execute: CREATE TABLE NESTED_FIELDS_ENTRY ( OBJ_ID integer, FK_ID DECIMAL (15,0), NAME VARCHAR (150), PRIMARY KEY(OBJ_ID) ) [torque-sql-exec] Failed to execute: CREATE TABLE INHERITANCE_MULTI_COMPANY ( OBJ_ID DECIMAL (15,0), NAME VARCHAR (150), PRIMARY KEY(OBJ_ID) ) [torque-sql-exec] Failed to execute: CREATE TABLE INHERITANCE_MULTI_EMPLOYEE ( OBJ_ID integer, OBJ_ID_2 DECIMAL (15,0), NAME VARCHAR (150), FK_ADDRESS integer, PRIMARY KEY(OBJ_ID,OBJ_ID_2) ) [torque-sql-exec] Failed to execute: CREATE TABLE INHERITANCE_MULTI_EXECUTIVE ( OBJ_ID integer, OBJ_ID_2 DECIMAL (15,0), SUPER_ID integer, SUPER_ID_2 DECIMAL (15,0), MANAGER_ID integer, MANAGER_ID_2 DECIMAL (15,0), DEPARTMENT VARCHAR (150), PRIMARY KEY(OBJ_ID,OBJ_ID_2) ) [torque-sql-exec] Failed to execute: CREATE TABLE INHERITANCE_MULTI_MANAGER ( OBJ_ID integer, OBJ_ID_2 DECIMAL (15,0), SUPER_ID integer, SUPER_ID_2 DECIMAL (15,0), PRIMARY KEY(OBJ_ID,OBJ_ID_2) ) [torque-sql-exec] Failed to execute: CREATE TABLE P_A_TABLE ( ID BIGINT, A_ATTRIB integer, PRIMARY KEY(ID) ) [torque-sql-exec] Failed to execute: CREATE TABLE P_B_TABLE ( ID BIGINT, B_ATTRIB integer, A_ID BIGINT, PRIMARY KEY(ID) ) [torque-sql-exec] Failed to execute: CREATE TABLE P_C_TABLE ( ID BIGINT, C_ATTRIB integer, C1_ATTRIB integer, B_ID BIGINT, D_ID BIGINT, PRIMARY KEY(ID) ) [torque-sql-exec] Failed to execute: CREATE TABLE P_D_TABLE ( ID BIGINT, D_ATTRIB integer, PRIMARY KEY(ID) ) [torque-sql-exec] Failed to execute: CREATE TABLE OJB_HL_SEQ ( TABLENAME VARCHAR (175), FIELDNAME VARCHAR (70), MAX_KEY BIGINT, GRAB_SIZE integer, VERSION integer, PRIMARY KEY(TABLENAME,FIELDNAME) ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: which version of spring will support cvs head?
On 10/27/05, Warner Onstine <[EMAIL PROTECTED]> wrote: > Hopefully a quick question, we are currently using spring 1.1.5, but > this appears to break with the latest from head (1.1.0 ?). I have > dropped in spring 1.2.5 and it appears to support what's in CVS I just > wanted to make sure. Yep, in general you should use the 1.2 line of Spring with OJB, though the 1.0.x versions should still work nicely with 1.1.5. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
which version of spring will support cvs head?
Hi all, Hopefully a quick question, we are currently using spring 1.1.5, but this appears to break with the latest from head (1.1.0 ?). I have dropped in spring 1.2.5 and it appears to support what's in CVS I just wanted to make sure. Thanks for the assistance! -warner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: java.lang.Integer not found in OJB Repository
Thanks for the help Armin. I had some problems with my application
code, but you were right, they collection was Integers. That pointed me
in the correct direction.
Thanks.
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 26, 2005 11:37 AM
To: OJB Users List
Subject: Re: java.lang.Integer not found in OJB Repository
Lemke, Wesley wrote:
> Sorry, I didn't get the debug jar in the right directory. Here is the
> correct stack trace, and it really has the line number this time!
>
The most important part of the stack trace seems to be >
org.apache.ojb.broker.core.PersistenceBrokerImpl.deleteCollections(Persi
> stenceBrokerImpl.java:692)
The associated code is:
if (cds.getCascadingDelete() ==
ObjectReferenceDescriptor.CASCADE_OBJECT)
{
Object col = cds.getPersistentField().get(obj);
if (col != null)
{
Iterator colIterator = BrokerHelper.getCollectionIterator(col);
while (colIterator.hasNext())
{
doDelete(colIterator.next()); // line 692
}
}
}
The colIterator.next() return an Integer object instead of the
persistent object to delete. So it seems that the populated 1:n
reference in StateDiscountUpdater contains Integer objects instead of
DiscountToUpdate objects.
Could you check this with a debugger?
regards,
Armin
> [10/26/05 10:55:53:579 CDT] 2650265 BaseRuntimeEx W
> com.lmig.pm.affinity.exception.BaseRuntimeException
> com.lmig.pm.affinity.exception.SystemException occurred. Reason: Error
> deleting object class
> com.lmig.pm.affinity.service.StateDiscountUpdater
> (caused by:
> org.apache.ojb.broker.metadata.ClassNotPersistenceCapableException:
> java.lang.Integer not found in OJB Repository)
> [10/26/05 10:55:53:579 CDT] 2650265 SystemErr R
> com.lmig.pm.affinity.exception.SystemException occurred. Reason: Error
> deleting object class
> com.lmig.pm.affinity.service.StateDiscountUpdater
> (caused by:
> org.apache.ojb.broker.metadata.ClassNotPersistenceCapableException:
> java.lang.Integer not found in OJB Repository)
> [10/26/05 10:55:53:629 CDT] 2650265 BaseException E
> com.lmig.pm.affinity.exception.BaseExceptionHandler
> ***There was an error
> [10/26/05 10:55:53:639 CDT] 2650265 BaseException E
> com.lmig.pm.affinity.exception.BaseExceptionHandler Error deleting
> object class com.lmig.pm.affinity.service.StateDiscountUpdater (caused
> by:
org.apache.ojb.broker.metadata.ClassNotPersistenceCapableException:
> java.lang.Integer not found in OJB Repository)
> [10/26/05 10:55:53:649 CDT] 2650265 SystemErr R
> com.lmig.pm.affinity.exception.SystemException: Error deleting object
> class com.lmig.pm.affinity.service.StateDiscountUpdater (caused by:
> org.apache.ojb.broker.metadata.ClassNotPersistenceCapableException:
> java.lang.Integer not found in OJB Repository)
> [10/26/05 10:55:53:659 CDT] 2650265 SystemErr R at
> java.lang.Throwable.(Throwable.java)
> [10/26/05 10:55:53:659 CDT] 2650265 SystemErr R at
> java.lang.Throwable.(Throwable.java)
> [10/26/05 10:55:53:659 CDT] 2650265 SystemErr R at
> com.lmig.pm.affinity.exception.BaseRuntimeException.(BaseRuntime
> Ex
> ception.java:85)
> [10/26/05 10:55:53:659 CDT] 2650265 SystemErr R at
> com.lmig.pm.affinity.persistence.PersistenceManager.delete(Persistence
> Ma
> nager.java:1356)
> [10/26/05 10:55:53:659 CDT] 2650265 SystemErr R at
> com.lmig.pm.affinity.service.DiscountUpdater.complete(DiscountUpdater.
> ja
> va)
> [10/26/05 10:55:53:659 CDT] 2650265 SystemErr R at
> com.lmig.pm.affinity.action.FinishClientScheduleDiscountUpdatesAction.
> do
> Perform(FinishClientScheduleDiscountUpdatesAction.java:74)
> [10/26/05 10:55:53:659 CDT] 2650265 SystemErr R at
> com.lmig.pm.affinity.action.AffinityAction.execute(AffinityAction.java
> :1
> 62)
> [10/26/05 10:55:53:669 CDT] 2650265 SystemErr R at
> org.apache.struts.action.RequestProcessor.processActionPerform(Request
> Pr
> ocessor.java:484)
> [10/26/05 10:55:53:669 CDT] 2650265 SystemErr R at
>
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:
> 274)
> [10/26/05 10:55:53:669 CDT] 2650265 SystemErr R at
>
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
> [10/26/05 10:55:53:669 CDT] 2650265 SystemErr R at
> org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
> [10/26/05 10:55:53:669 CDT] 2650265 SystemErr R at
>
com.lmig.pm.affinity.servlet.ActionServlet.doGet(ActionServlet.java:49)
> [10/26/05 10:55:53:669 CDT] 2650265 SystemErr R at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
> [10/26/05 10:55:53:669 CDT] 2650265 SystemErr R at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> [10/26/05 10:55:53:669 CDT] 2650265 SystemErr R at
> com.ibm.ws.webcontainer.servlet.StrictServletInstance.doService(Strict
> Se
> rvletInstance.java:110)
> [10/26/05
Re: Using OJB with Oracle Packages and Procedures - simple Question
Hi Ron, thanks for that! I will checkout my needs against this howto. Thanks for your time, -- Fernando Bernardino On 10/26/05, Ron Gallagher <[EMAIL PROTECTED]> wrote: > Fernando -- > > OJB can be configured to use Oracle packages/procedures for all CRUD > operations. See > http://db.apache.org/ojb/docu/howtos/howto-work-with-stored-procedures.html > for details on how. As far as using packages/procedures for queries, I > don't think support for that is present, or even planned for. > > Ron Gallagher > > -Original Message- > From: Fernando Bernardino [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 26, 2005 9:01 AM > To: ListaOJB > Subject: Using OJB with Oracle Packages and Procedures - simple Question > > Hello people! > > I'm creating a app for a mobile phone/PDA's/Palms. This app connect to a > servlet server and uses request/response to send/get the information. The > client is an AWT frame. > > In the server, I'm using Struts to control my servlets and I'm thinking > about to use OJB to control my DAO's. > > But I have to work with PKG's/PRC's from Oracle. Can I do that with OJB? Is > that recomended from you guys? > > Thanks for your's attention. (Sorry my english..) > > > -- > Fernando Bernardino > > - > 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: M:N storage removes duplicate elements
On Oct 27, 2005, at 05:53, Armin Waibel wrote:
Hi Jason,
> For instance:
>
> Foo foo1 = new Foo();
> Bar bar1 = new Bar();
>
> broker.beginTransaction();
> broker.store( bar1 );
> broker.store( foo1 );
>
> bar1.getFoos().add( foo1 );
> bar1.getFoos().add( foo1 );
>
> broker.store( bar1 );
> broker.commitTransaction();
>
> I would expect the above to result in an insert into the foo
table, an
> insert into the bar table, and 2 insertions into the foo_bar
table. I
> get the expected behavior in the foo and bar tables, but I only
get one
> new record into the foo_bar table.
I think this is the intended behavior. You add the same foo object
twice in bar - why and how should OJB differ? You expect 2 entries
in indirection table for the same bar/foo combination?
How did OJB notice the autoincrement 'id' column in foo_bar?
Armin,
I expect two entries in indirection table for the same bar/foo
combination _at different indices_ of the collection being preserved.
When I turn SQL generation debugging on via log4j like this:
log4j.logger.org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultIm
pl=DEBUG
I get output like the following:
DEBUG [TP-Processor7] (?:?) - SQL:INSERT INTO bar (name) VALUES (?)
DEBUG [TP-Processor7] (?:?) - SQL:INSERT INTO foo (name) VALUES (?)
DEBUG [TP-Processor7] (?:?) - SQL:INSERT INTO foo_bar (bar_id,foo_id)
VALUES (?,?)
DEBUG [TP-Processor7] (?:?) - SQL:INSERT INTO foo_bar (bar_id,foo_id)
VALUES (?,?)
versus the PSpy output for the very same execution:
1130385321625|33|0|statement||select count(*) from foo
1130385321712|2|0|statement||INSERT INTO bar (name) VALUES ('bar1')
1130385321729|4|0|statement||SELECT LAST_INSERT_ID() FROM bar LIMIT 1
1130385321768|2|0|statement||INSERT INTO foo (name) VALUES ('foo1')
1130385321770|2|0|statement||SELECT LAST_INSERT_ID() FROM foo LIMIT 1
1130385321774|2|0|statement||INSERT INTO foo (name) VALUES ('foo2')
1130385321776|2|0|statement||SELECT LAST_INSERT_ID() FROM foo LIMIT 1
1130385321808|2|0|statement||INSERT INTO foo_bar (bar_id,foo_id)
VALUES ('14','17')
1130385321836|1|0|commit||
So it seems to me that OJB is suppressing an insertion into the
indirection table. My educated guess was that perhaps within the
transaction it was checking to see if it had already inserted a value
in the indirection table for that bar/foo combination, and not
performing the insertion the 2nd - Nth times it encounters that pairing.
- Jason
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: M:N storage removes duplicate elements
Hi Jason, > For instance: > > Foo foo1 = new Foo(); > Bar bar1 = new Bar(); > > broker.beginTransaction(); > broker.store( bar1 ); > broker.store( foo1 ); > > bar1.getFoos().add( foo1 ); > bar1.getFoos().add( foo1 ); > > broker.store( bar1 ); > broker.commitTransaction(); > > I would expect the above to result in an insert into the foo table, an > insert into the bar table, and 2 insertions into the foo_bar table. I > get the expected behavior in the foo and bar tables, but I only get one > new record into the foo_bar table. I think this is the intended behavior. You add the same foo object twice in bar - why and how should OJB differ? You expect 2 entries in indirection table for the same bar/foo combination? How did OJB notice the autoincrement 'id' column in foo_bar? regards, Armin Jason A. Lunn wrote: I have an indirection table foo_bar that happily implements an m:n relationship between foo and bar. the columns of foo_bar include foo_id, bar_id, and a unique id for the association itself (mysql backend, the id column is inserted automatically). This is because it is relevant to my application to materialize references to the same object at different indices of the collection upon retrieval. I started out doing all the insertion into this table by hand. When I retrieve foo or bar, I successfully get a collection containing all the expected elements at all the right indices. But now I'm trying to get more sophisticated, and thus writing an online editor for this relationship instead of populating the foo_bar table through the mysql command line. What I'm finding is that OJB is deduping my collection by ignoring successive references to elements it has already seen in the current transaction. The result is that I don't get as many rows inserted into my indirection table as I want. For instance: Foo foo1 = new Foo(); Bar bar1 = new Bar(); broker.beginTransaction(); broker.store( bar1 ); broker.store( foo1 ); bar1.getFoos().add( foo1 ); bar1.getFoos().add( foo1 ); broker.store( bar1 ); broker.commitTransaction(); I would expect the above to result in an insert into the foo table, an insert into the bar table, and 2 insertions into the foo_bar table. I get the expected behavior in the foo and bar tables, but I only get one new record into the foo_bar table. Someone I know suggested that I manually iterate over the collection using the link() and unlink() methods of BrokerHelper, but I was convinced that there was a more elegant way to do this, possibly a configuration file tweak to tell OJB to create multiple links in the indirection table rather than assuming that I only want one. Your thoughts appreciated. - Jason - 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: PB.store extremely slow
Hi, just one more piece of information: If I set auto-update="none" on either "groups" or "users" the storing is fast. So I think there is happening a "cycle" because a store on a users results in a store of a group which in turn results in a store of all users in that group. I don't know if this is a bug or a feature ;-) What do you think? Tino Tino Schöllhorn wrote: Hi, we are using OJB 1.0.1 and we have found a very strange issue: We have a class "User" and a class "Group". Now we have a quite common and simple use-case that a User becomes member of a Group. The code for this is like: User user = ...; Group group = ...; user.addGroup(group); pb.beginTransaction(); pb.store(user); pb.commitTransaction(); So far so good. But now it gets weird: If one has many users the pb.store()-part takes ages. Java and the database (in my case: mysql) take a very large part of the cpu-performance. Is this a known issue with 1.0.1 so we can change ojb? Or are we doing something completely wrong? I suppose it has something to do with the auto-*-settings, but we are using those in other use-cases as well and have no problems there. The class-descriptors are defined like (fields have been ommited): ... collection-class="org.apache.ojb.broker.util.collections.ManageableArrayList" element-class-ref="kos.wnetz.om.Group" auto-retrieve="true" auto-update="object" auto-delete="link" proxy="false" indirection-table="tk_group_user"> attribute-value="users"/> ... name="users" collection-class="org.apache.ojb.broker.util.collections.ManageableArrayList" element-class-ref="kos.wnetz.om.User" auto-retrieve="true" auto-update="object" auto-delete="link" proxy="true" indirection-table="tk_group_user"> attribute-value="groups"/> I am glad for any help With regards Tino - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
PB.store extremely slow
Hi, we are using OJB 1.0.1 and we have found a very strange issue: We have a class "User" and a class "Group". Now we have a quite common and simple use-case that a User becomes member of a Group. The code for this is like: User user = ...; Group group = ...; user.addGroup(group); pb.beginTransaction(); pb.store(user); pb.commitTransaction(); So far so good. But now it gets weird: If one has many users the pb.store()-part takes ages. Java and the database (in my case: mysql) take a very large part of the cpu-performance. Is this a known issue with 1.0.1 so we can change ojb? Or are we doing something completely wrong? I suppose it has something to do with the auto-*-settings, but we are using those in other use-cases as well and have no problems there. The class-descriptors are defined like (fields have been ommited): ... collection-class="org.apache.ojb.broker.util.collections.ManageableArrayList" element-class-ref="kos.wnetz.om.Group" auto-retrieve="true" auto-update="object" auto-delete="link" proxy="false" indirection-table="tk_group_user"> ... collection-class="org.apache.ojb.broker.util.collections.ManageableArrayList" element-class-ref="kos.wnetz.om.User" auto-retrieve="true" auto-update="object" auto-delete="link" proxy="true" indirection-table="tk_group_user"> I am glad for any help With regards Tino - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: Inheritance using special attribute ojbConcreteClass issue]
Thomas Dudziak wrote: Might be either the XDoclet module or Torque. Could you post the generated repository file ? I found out what the Problem ist, I guess. The accept-data.xml generated by Torque contains the java attribute names instead of the data base column names, so in: the content is ambiguous. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
