Re: OJB 0.99 writing to the database in jboss! Please help
Hi, I ran into the same problem. Is there a solution avail? cheers, Guido - Original Message - From: Ashraf Moosa [EMAIL PROTECTED] To: OJB Users List [EMAIL PROTECTED] Sent: Tuesday, February 18, 2003 10:09 AM Subject: OJB 0.99 writing to the database in jboss! Please help Hi, I am having the same problems as Cristos. I am upgrading from version 0.9.8. I can successfully read from the database but when I try to add or update everything executes cleanly but nothing commits to the database. I have tried in with implicit locking set to true as well as false. Ashraf On Fri, 2003-02-14 at 13:02, Cristos Dimitriou wrote: Hi all, I have recently upgrade to Version 0.9.9. Currently the environment that i am running is a managed environment(JBOSS) connecting to a postgres db. I am having problems writing to the database, more specifically, the application executes cleanly with no runtime errors however no values have been writen to the db. It seems that i have only aquired a read lock to the database but the code that I am using in order to obtain a database is as follows: db.open(default#user#pwd,Database.OPEN_READ_WRITE); Does anyone have any ideas? Thanks in advance Cristos Dimitriou - 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]
JUnit-Build with MySQL failed: do I have to change something?
Output: ---snip--- junit-no-compile-no-prepare: [junit] Running org.apache.ojb.broker.AllTests [junit] Tests run: 174, Failures: 3, Errors: 3, Time elapsed: 20,703 sec [junit] TEST org.apache.ojb.broker.AllTests FAILED [junit] Running org.apache.ojb.odmg.AllTests [junit] [BOOT] INFO: OJB.properties: file:/C:/jakarta-ojb-0.9.9/target/test/ojb/OJB.properties [junit] Tests run: 147, Failures: 1, Errors: 2, Time elapsed: 10,421 sec [junit] TEST org.apache.ojb.odmg.AllTests FAILED [junit] Running org.apache.ojb.soda.AllTests [junit] [BOOT] INFO: OJB.properties: file:/C:/jakarta-ojb-0.9.9/target/test/ojb/OJB.properties [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 1,328 sec junit-no-compile: junit: BUILD SUCCESSFUL Total time: 1 minute 9 seconds end--- hint: mysql-server runs on localhost and can be accessed I did the changes in build.bat and mysql.profile and build.properties equip: jdk 1.4.1 win2000 SP 3 joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JUnit-Build with MySQL failed: do I have to change something?
Hi Joerg, does not look bad for be. have a look at the target/test/*test.txt files that contain the junit output to see which testcases failed. May be it's just some special stuff that does not fit together, but that you do not rely on. Nothing to worry about in most cases. cheers, Thomas -Original Message- From: Joerg Lensing [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 26, 2003 2:00 PM To: OJB Users List Subject: JUnit-Build with MySQL failed: do I have to change something? Output: ---snip--- junit-no-compile-no-prepare: [junit] Running org.apache.ojb.broker.AllTests [junit] Tests run: 174, Failures: 3, Errors: 3, Time elapsed: 20,703 sec [junit] TEST org.apache.ojb.broker.AllTests FAILED [junit] Running org.apache.ojb.odmg.AllTests [junit] [BOOT] INFO: OJB.properties: file:/C:/jakarta-ojb-0.9.9/target/test/ojb/OJB.properties [junit] Tests run: 147, Failures: 1, Errors: 2, Time elapsed: 10,421 sec [junit] TEST org.apache.ojb.odmg.AllTests FAILED [junit] Running org.apache.ojb.soda.AllTests [junit] [BOOT] INFO: OJB.properties: file:/C:/jakarta-ojb-0.9.9/target/test/ojb/OJB.properties [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 1,328 sec junit-no-compile: junit: BUILD SUCCESSFUL Total time: 1 minute 9 seconds end--- hint: mysql-server runs on localhost and can be accessed I did the changes in build.bat and mysql.profile and build.properties equip: jdk 1.4.1 win2000 SP 3 joerg - 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: OJB/Postgres configuration recipe?
Hi Yuji, We currently have about 6 failures and errors in CVS head. SO having 12 problems with a non-hsqldb platform is not bad. Did you check the junit logs under target/test ? Do the logs indicate any problems with functionality that you need? In most cases it's only some special things that do not work, but do only affect 1% of all applications. cheers, Thomas -Original Message- From: Yuji Shinozaki [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 26, 2003 2:38 PM To: OJB Users List Subject: OJB/Postgres configuration recipe? Does someone have a recipe for configuring OJB with Postgres (7.3.2)? I have just started using OJB, and I have the task of applying it to a project (with a fairly short deadline). The mapping and caching features promise to be a tremendous time saver, but I am now stuck on getting the junit tests to resolve satisfactorily. I am getting about over 12 failures and errors in the junit tests (the PB tests mainly) using both ojb-0.9.9 and the ojb from CVS HEAD. I am using postgres 7.3.2 with the latest stable jdbc3 driver. I have tried various profiles settings, but the junit failures remain about constant. Now, I know there are some failures due to the state of the ojb codebase but they seem to account for only 3 of them. Before I start diving deeper into the configuration, could someone tell me a configuration which has worked for them to use as a starting point? OR pointers to issues that I should deal with? Thanks! yuji Yuji ShinozakiComputer Systems Senior Engineer [EMAIL PROTECTED] Advanced Technologies Group (804)924-7171 Information Technology Communication http://www.people.virginia.edu/~ys2nUniversity of Virginia - 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: auditing mapped classes
afterLookup is fired regardless of whether it was cached or from the database. -Original Message- From: Ebersole, Steven [mailto:[EMAIL PROTECTED] Sent: 26 February 2003 14:31 To: 'OJB Users List' Subject: RE: auditing mapped classes The PersistenceBrokerListener could definitely be used as a start for this functionality along the lines you mention. A quick question, how does using caching affect the afterLookup event? Is this event only fired when an object is materialized from the DB, or after any lookup (regardless of whether found in cache or loaded from DB)? The transaction knowledge depends on what you are trying to accomplish. For example, another thing I need to perform is that if an object changed, update its audit fields. However, a txn-commiting type event is (at least has been) problematic because my event processing needs to be included in the transaction. And even for the audtiting requirment I mentioned earlier, as long as the event-hub and/or audting gateway is transactional, I don't think knowledge of the PB transaction is necessarily required; at least for my specs and given my limited understanding of OJB. My plan would basically be to: 1) On afterLookup event, store a deep copy of the object just read; 2) On beforeStore calculate the instance's changeset (using the TopLink term); if (changes occurred) Publish change to the domain-event-hub reset the domain objects audit fields else Do nothing Or I could just leave the journalling as part of the domain objects themselves. I'll have to think about this some more. |-Original Message- |From: Charles Anthony [mailto:[EMAIL PROTECTED] |Sent: Wednesday, February 26, 2003 2:28 AM |To: 'OJB Users List' |Subject: RE: auditing mapped classes | | |Hi, | |I think it *may* be possible using the |PersistenceBrokerListener mechanism. |The PersistenceBrokerListener is an interface, |implementations of which can |be added to a persistence broker. |It has call-backs for when objects are looked up, and |when they are |stored (among other events). | |You could copy the objects attributes after looking up, |and compare them |when they are stored. | |This is essentially what the ODMG layer is doing, but in a |different way. | |The one caveat would be (and I need to solve this for a |problem myself) is |knowing when the PersistenceBroker transaction is |committed/rolled back - |that is really when you would want to compare the |attributes of stored |objects. This should be possible by adding the appropriate |callbacks to the |PBListener mechanism. | |HTH a little, | |Cheers, | |Charles. | | |-Original Message- |From: Ebersole, Steven [mailto:[EMAIL PROTECTED] |Sent: 25 February 2003 20:39 |To: 'OJB Users List' |Subject: RE: auditing mapped classes | | |I think ideally this fits as low on the persistence mechanism |as possible |(i.e., the DB). However, the thought of implementing |this as a web of |triggers, when I have a nice Object layer directly above, just |seems silly. | |I impetus behind this is that I am writing a thin interface |layer over (and |hiding) the particular O/R implementation; much like you have |spoken about |on this list quite a few times. Currently Castor is built and |OJB is a work |in progress and TopLink is on the horizon. Castor has no |such concept, |although they too have the callback mechanism. This is what |lead me to the |InvocationHandler/Map/Journaler approach. Basically the |domain objects |extend a base, which instantiates a |InvocationHandler-wrapped Map and |listens for persistence callbacks. The Map also has an attached |Journaller responsible for maintaining changes state of |the object |(similiar to the DB concept). At transaction start, it |initiailizes the |Journaler and begins recording changes. At commit, it |notifies an EventHub |which is responsible for in turn notifying the |integration and audting |gateways. | |Then, on doing some advanced scouting on the TopLink stuff, I |noticed the |changeset stuff and thought it would be really, really nice to |have this |refactored out of the domain classes theselves. I guess, I |wasn't thinking |of the processing integrated into the O/R layer, just a |callback-level |interface so that parallel systems could basically |register interest in |changes. | |With the OJB persistence wrapping, I was hoping to utilize the |PB approach. |But it sounds like this will not be possible. | | | ||-Original Message- ||From: Thomas Mahler [mailto:[EMAIL PROTECTED]
addLike and integer fields
Hi, Is there an issue in OJB with performing like queries with integer fields. I'm trying to use the following criteria: crit.addLike( internalProductID, % + Integer.toString(theProductModel.getInternalProductID()) + % ); Query query = new QueryByCriteria(ProductModel.class, crit, true); Collection lListOfProducts = getBroker().getCollectionByQuery(query); The field descriptor is as follows: field-descriptor name=internalProductID column=INTERNAL_PRODUCT_ID jdbc-type=INTEGER primarykey=true autoincrement=true sequence-name=product_id_seq/ When I run the code I above I get an exception (strack trace shown below). There isn't any issue when I run something like the following sql directly: select * from products where internal_product_id like '%25%' Also, the above works fine for 'VARCHAR' fields. Thanks, John java.lang.ClassCastException: java.lang.String at oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatement .java:2021) at oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatement .java:2102) at com.p6spy.engine.spy.P6PreparedStatement.setObject(P6PreparedStatement.java: 282)at org.apache.ojb.broker.platforms.PlatformDefaultImpl.setObjectForStatement(Pl atformDefaultImpl.java:229) at org.apache.ojb.broker.platforms.PlatformOracleImpl.setObjectForStatement(Pla tformOracleImpl.java:126) at org.apache.ojb.broker.accesslayer.StatementManager.bindStatementValue(Statem entManager.java:258)at org.apache.ojb.broker.accesslayer.StatementManager.bindStatement(StatementMa nager.java:297) at org.apache.ojb.broker.accesslayer.StatementManager.bindSelectionCriteria(Sta tementManager.java:490) at org.apache.ojb.broker.accesslayer.StatementManager.bindStatement(StatementMa nager.java:451) at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(JdbcAccessImpl .java:258) at org.apache.ojb.broker.accesslayer.RsIterator.init(RsIterator.java:175) at org.apache.ojb.broker.singlevm.RsIteratorFactoryImpl.createRsIterator(RsIter atorFactoryImpl.java:95)at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getRsIteratorFromQuery( PersistenceBrokerImpl.java:2146)at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getIteratorFromQuery(Pe rsistenceBrokerImpl.java:1550) at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(Pe rsistenceBrokerImpl.java:1235) at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(Pe rsistenceBrokerImpl.java:1363) at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(Pe rsistenceBrokerImpl.java:1389) at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(Pe rsistenceBrokerImpl.java:1376) at org.apache.ojb.broker.singlevm.DelegatingPersistenceBroker.getCollectionByQu ery(DelegatingPersistenceBroker.java:294) at ie.mcps.product.dao.ProductDAO.searchForProduct(ProductDAO.java:509) This e-mail and any files transmitted with it are confidential and may be privileged and are intended solely for the individual named/ for the use of the individual or entity to whom they are addressed.If you are not the intended addressee, you should not disseminate, distribute or copy this e-mail.Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system.If you are not the intended recipient, you are notified that reviewing, disclosing, copying, distributing or taking any action in reliance on the contents of this e-mail is strictly prohibited.Please note that any views or opinions expressed in this e-mail are solely those of the author and do not necessarily represent those of Traventec Limited.E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, or arrive late or incomplete.Traventec Limited therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.The recipient should check this e-mail and any attachments for the presence of viruses.This e-mail has been swept for computer viruses however Traventec Limited accepts no liability for any damage caused by any virus transmitted by this e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
NoSuchElementException with getIteratorByQuery and getCollectionByQuery
Hi all, I have an error when accesing a Iterator iter = broker.getIteratorByQuery(query); or Collection aux = broker.getCollectionByQuery(query); the error: java.util.NoSuchElementException at org.apache.ojb.broker.accesslayer.RsIterator.next(Unknown Source).. any idea?? thanks in advanced Ferran Parra Departament de Noves Tecnologies [EMAIL PROTECTED] MUBIMEDIA S.L. -- Mallorca, 275, 1r 2a 08008 BARCELONA T. (+34) 93 215 21 91 F. (+34) 93 215 41 21 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: NoSuchElementException with getIteratorByQuery and getCollectionByQuery
Check that your jdbc driver is JDBC 2.0 compliant; it's mandatory in order to getIteratorByQuery or getCollectionByQuery works fine. http://objectbridge.sourceforge.net/javadoc/ojb/broker/accesslayer/RsIterato r.html Cheers!! :) -Mensaje original- De: Ferran Parra [mailto:[EMAIL PROTECTED] Enviado el: miércoles 26 de febrero de 2003 16:47 Para: OJB Users List Asunto: NoSuchElementException with getIteratorByQuery and getCollectionByQuery Hi all, I have an error when accesing a Iterator iter = broker.getIteratorByQuery(query); or Collection aux = broker.getCollectionByQuery(query); the error: java.util.NoSuchElementException at org.apache.ojb.broker.accesslayer.RsIterator.next(Unknown Source).. any idea?? thanks in advanced Ferran Parra Departament de Noves Tecnologies [EMAIL PROTECTED] MUBIMEDIA S.L. -- Mallorca, 275, 1r 2a 08008 BARCELONA T. (+34) 93 215 21 91 F. (+34) 93 215 41 21 - 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: NoSuchElementException with getIteratorByQuery and getCollectionByQuery
Hi Luis the JDBC driver is 2.0 compliant is a mm.mysql-2.0.14-bin.jar for mysql thanks - Original Message - From: luis barreiro [EMAIL PROTECTED] To: OJB Users List [EMAIL PROTECTED] Sent: Wednesday, February 26, 2003 4:03 PM Subject: RE: NoSuchElementException with getIteratorByQuery and getCollectionByQuery Check that your jdbc driver is JDBC 2.0 compliant; it's mandatory in order to getIteratorByQuery or getCollectionByQuery works fine. http://objectbridge.sourceforge.net/javadoc/ojb/broker/accesslayer/RsIterato r.html Cheers!! :) -Mensaje original- De: Ferran Parra [mailto:[EMAIL PROTECTED] Enviado el: miércoles 26 de febrero de 2003 16:47 Para: OJB Users List Asunto: NoSuchElementException with getIteratorByQuery and getCollectionByQuery Hi all, I have an error when accesing a Iterator iter = broker.getIteratorByQuery(query); or Collection aux = broker.getCollectionByQuery(query); the error: java.util.NoSuchElementException at org.apache.ojb.broker.accesslayer.RsIterator.next(Unknown Source).. any idea?? thanks in advanced Ferran Parra Departament de Noves Tecnologies [EMAIL PROTECTED] MUBIMEDIA S.L. -- Mallorca, 275, 1r 2a 08008 BARCELONA T. (+34) 93 215 21 91 F. (+34) 93 215 41 21 - 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]
TransactionAbortedException
My web application using OJB is working fine after I deploy it -- I can create, update, delete, and load objects with no problems. However, if I leave the app deployed, and try to perform a commit the next day, I get the following exception (stack trace included). It seems like something is timing out, but I don't know what. Does anyone have any ideas? Just for background info, I am using Struts 1.1 beta 3. org.odmg.TransactionAbortedException at org.apache.ojb.odmg.ObjectEnvelopeTable.commit(Unknown Source) at org.apache.ojb.odmg.TransactionImpl.doCommitOnObjects(Unknown Source) at org.apache.ojb.odmg.TransactionImpl.prepare(Unknown Source) at org.apache.ojb.odmg.TransactionImpl.commit(Unknown Source) at org.ghsbaseball.service.ContentServiceImpl.updateTeam(Unknown Source) at org.ghsbaseball.roster.ModifyTeamActions.update(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.struts.actions.DispatchAction.dispatchMethod(DispatchAction.java: 278) at org.apache.struts.actions.LookupDispatchAction.execute(LookupDispatchAction. java:234) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProces sor.java:465) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1422) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:523) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase .java:550) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180 ) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve. java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172 ) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:432) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne ction(Http11Protocol.java:386) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:534) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:530) at java.lang.Thread.run(Thread.java:536) - To
Required Jars
Hello all, I am just getting started with OJB as well. I plan on using OJB with Tomcat. The OJB documentation recommends copying all of the jar files under the jakarta-ojb-0.9.9\lib directory to the WEB-INF/lib directory. I tried it. After copying these files, Tomcat will not start the web application. For those who have had success using OJB with Tomcat, could you share how you set it up? Thanks, Joshua This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Required Jars
I am using OJB 0.9.8 with Tomcat 4.1.12. Take a look at the output from the Tomcat log file. Is there something in there that indicates why the web app cannot start? -- david -Original Message- From: White, Joshua A (CASD, IT) [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 26, 2003 10:34 AM To: 'OJB Users List' Subject: Required Jars Hello all, I am just getting started with OJB as well. I plan on using OJB with Tomcat. The OJB documentation recommends copying all of the jar files under the jakarta-ojb-0.9.9\lib directory to the WEB-INF/lib directory. I tried it. After copying these files, Tomcat will not start the web application. For those who have had success using OJB with Tomcat, could you share how you set it up? Thanks, Joshua This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. - 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]
Using JDO metadata file for OR mapping
In JDO mode, does OJB currently requires the O-R-mapping to take place in the repository.xml or can OJB use a metadata.jdo file for mapping too? Regards, Sebastian -- __ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Required Jars
Try removing servlet.jar Jose Manuel. -Mensaje original- De: White, Joshua A (CASD, IT) [mailto:[EMAIL PROTECTED] Enviado el: miércoles, 26 de febrero de 2003 17:34 Para: 'OJB Users List' Asunto: Required Jars Hello all, I am just getting started with OJB as well. I plan on using OJB with Tomcat. The OJB documentation recommends copying all of the jar files under the jakarta-ojb-0.9.9\lib directory to the WEB-INF/lib directory. I tried it. After copying these files, Tomcat will not start the web application. For those who have had success using OJB with Tomcat, could you share how you set it up? Thanks, Joshua This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ---Publicidad Únete a los miles de sin pareja en Meetic... ¡te vas a enamorar! http://www.iespana.es/_reloc/email.meetic ---Publicidad Juega con Ventura24.es, lotería inteligente y multiplica tus posibilidades!! http://www.iespana.es/_reloc/email.ventura - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Torque XML and Java generation
We're using a customized set of the templates that come with torque-3.0, so I cant tell you what's changed in those since, but I downloaded the db-torque cvs project and see that they've split off the generator portion (the part we use, which generates schemas and sql). Theres a small mention of it on the torque home page. I had pretty good success using the generator to create ddl code to create a postgres equivalent to our normally-SQLServer application database. I have no idea yet how to copy data from one to the other though (especially since one is at work and one is at home). It did take a little setup time to get all the required folders and files needed by the app though. I copied our xml database schema file to the proper folder, set the build.properties to say postgresql, and set the postgres profile to point to my database, then ran the sql target on the build-torque file that comes from the conf subfolder in the torque project. The generated postgres-type sql files, which ended up in src/sql were -almost- right for me :) I had to do a couple search-n-replaces on the sql because the code to delete old sequences doesnt use quite the correct name for the sequence. I havent bothered to modify the template, since im not going to be generating this file very often. -dave -Original Message- From: Brian McCallister [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 26, 2003 7:37 AM To: OJB Users List Subject: Torque XML and Java generation I intended to ask this on the Torque list, but as it is bouncing on both db.apache.org and jakarta.apache.org... Does anyone here know the state of the OJB XML and Java class sources from Torque descriptors? The Torque site lists it as experimental. Thanks, Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +-+ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. +-+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generate table definitions?
That would be of interest to me as well, perhaps you could post it to this list? Dennis [EMAIL PROTECTED] wrote: Hi Jeff! I just figured it out myself. It works and its pretty slick. If you want I can put the steps in an email and send it your way. Someone really needs to help project out with something like a getting started guide. I'd appreciate it very much if you would do so! Thank you for the offer. Gabe Just let me know if you still need assistance, Jeff On Tuesday 25 February 2003 05:47 pm, you wrote: Hi there! I'm sure this has been asked many times here, but I'm wondering what the steps are to generate SQL tables from my repository.xml files. I've been puzzling over Torque for a few hours now. I'm missing something somewhere. Any help or pointers to relevant documentation would be appreciated. Gabe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Custom collection proxy
hi all, i'd like to try implement my own collection proxy class, what i'm doing is to refer to the source of CollectionProxy and code my own proxy class, however, no matter how i configure my collection descriptor, it stills doesn't work, can sbd help? collection-descriptor name=permissions collection-class=hk.com.mydomain.domain.basic.BusinessObjectListProxy element-class-ref=hk.com.mydomain.domain.security.UserPermission auto-retrieve=true auto-update=true auto-delete=true proxy=true inverse-foreignkey field-ref=ownerPrimaryKey / /collection-descriptor Best Regards, Jemmee Yung My Domain Consultant Limited http://my-domain.com.hk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom collection proxy
hi jemmee, i recently added this feature to ojb. the class to be used can be configured in ojb.properties: ... # # CollectionProxy class # # The optional CollectionProxy entry defines the class to be used for CollectionProxies # if this entry is null org.apache.ojb.broker.accesslayer.ListProxy is used for Lists # and org.apache.ojb.broker.accesslayer.CollectionProxy for Collections # #CollectionProxyClass= ... hth jakob Jemmee Yung wrote: hi all, i'd like to try implement my own collection proxy class, what i'm doing is to refer to the source of CollectionProxy and code my own proxy class, however, no matter how i configure my collection descriptor, it stills doesn't work, can sbd help? collection-descriptor name=permissions collection-class=hk.com.mydomain.domain.basic.BusinessObjectListProxy element-class-ref=hk.com.mydomain.domain.security.UserPermission auto-retrieve=true auto-update=true auto-delete=true proxy=true inverse-foreignkey field-ref=ownerPrimaryKey / /collection-descriptor Best Regards, Jemmee Yung My Domain Consultant Limited http://my-domain.com.hk/ - 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: addLike and integer fields
hi john, how does sql handle like with integers ? jakob O'Reilly John wrote: Hi, Is there an issue in OJB with performing like queries with integer fields. I'm trying to use the following criteria: crit.addLike( internalProductID, % + Integer.toString(theProductModel.getInternalProductID()) + % ); Query query = new QueryByCriteria(ProductModel.class, crit, true); Collection lListOfProducts = getBroker().getCollectionByQuery(query); The field descriptor is as follows: field-descriptor name=internalProductID column=INTERNAL_PRODUCT_ID jdbc-type=INTEGER primarykey=true autoincrement=true sequence-name=product_id_seq/ When I run the code I above I get an exception (strack trace shown below). There isn't any issue when I run something like the following sql directly: select * from products where internal_product_id like '%25%' Also, the above works fine for 'VARCHAR' fields. Thanks, John java.lang.ClassCastException: java.lang.String at oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatement .java:2021) at oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatement .java:2102) at com.p6spy.engine.spy.P6PreparedStatement.setObject(P6PreparedStatement.java: 282)at org.apache.ojb.broker.platforms.PlatformDefaultImpl.setObjectForStatement(Pl atformDefaultImpl.java:229) at org.apache.ojb.broker.platforms.PlatformOracleImpl.setObjectForStatement(Pla tformOracleImpl.java:126) at org.apache.ojb.broker.accesslayer.StatementManager.bindStatementValue(Statem entManager.java:258)at org.apache.ojb.broker.accesslayer.StatementManager.bindStatement(StatementMa nager.java:297) at org.apache.ojb.broker.accesslayer.StatementManager.bindSelectionCriteria(Sta tementManager.java:490) at org.apache.ojb.broker.accesslayer.StatementManager.bindStatement(StatementMa nager.java:451) at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(JdbcAccessImpl .java:258) at org.apache.ojb.broker.accesslayer.RsIterator.init(RsIterator.java:175) at org.apache.ojb.broker.singlevm.RsIteratorFactoryImpl.createRsIterator(RsIter atorFactoryImpl.java:95)at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getRsIteratorFromQuery( PersistenceBrokerImpl.java:2146)at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getIteratorFromQuery(Pe rsistenceBrokerImpl.java:1550) at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(Pe rsistenceBrokerImpl.java:1235) at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(Pe rsistenceBrokerImpl.java:1363) at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(Pe rsistenceBrokerImpl.java:1389) at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(Pe rsistenceBrokerImpl.java:1376) at org.apache.ojb.broker.singlevm.DelegatingPersistenceBroker.getCollectionByQu ery(DelegatingPersistenceBroker.java:294) at ie.mcps.product.dao.ProductDAO.searchForProduct(ProductDAO.java:509) This e-mail and any files transmitted with it are confidential and may be privileged and are intended solely for the individual named/ for the use of the individual or entity to whom they are addressed.If you are not the intended addressee, you should not disseminate, distribute or copy this e-mail.Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system.If you are not the intended recipient, you are notified that reviewing, disclosing, copying, distributing or taking any action in reliance on the contents of this e-mail is strictly prohibited.Please note that any views or opinions expressed in this e-mail are solely those of the author and do not necessarily represent those of Traventec Limited.E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, or arrive late or incomplete.Traventec Limited therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.The recipient should check this e-mail and any attachments for the presence of viruses.This e-mail has been swept for computer viruses however Traventec Limited accepts no liability for any damage caused by any virus transmitted by this e-mail. - 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 querys constraints
hi all,
i just added some fixes to support customizable 1:n queries.
just add a query-customizer class to the collection-descriptor.
this class must implement the QueryCustomizer interface, a
QueryCustomizerDefaultImpl is alreay there as a base class.
...
query-customizer
class=org.apache.ojb.broker.accesslayer.QueryCustomizerDefaultImpl
attribute
attribute-name=attr1
attribute-value=value1
/
...
the interface defines the single method below which is used to customize
(or completely rebuild) the query passed as argument. the interpretation
of attribute-name ans attribute-value is up to your class !
/**
* Return a new Query based on the original Query, the originator
object and
* the additional Attributes
*
* @param anObject the originator object
* @param aBroker the PersistenceBroker
* @param aCod the CollectionDescriptor
* @param aQuery the original 1:n-Query
* @return Query the customized 1:n-Query
*/
public Query customizeQuery(Object anObject, PersistenceBroker
aBroker, CollectionDescriptor aCod, Query aQuery);
hth
jakob
sclark wrote:
Jakob,
You are correct; all of the logic is in the Builder class. As you say,
there are lots of possibilities for these constraints. I think that the
best way to express them is to use Java, rather than trying to invent some
new syntax that fits inside of XML. And I bet that a fairly small set of
stock builders, appropriately parameterized, would hit the vast majority
of cases.
Hmmm ... I bet it would be quite easy to write an OqlQueryBuilder
which would take a single parameter, an OQL string, and parse it.
Imagine this:
class-descriptor class=Employee ...
collection-descriptor
name=recentOutsideProjects
elementClass=Project
...
inverse-foreignkey field-ref=employeeId /
query class=OqlQueryBuilder
attribute
attribute-name=queryString
attribute-value=project.startDate.year 2000 and project.org emp.org
/
/query
/collection-descriptor
Heck, maybe we could even write:
collection-descriptor
name=recentOutsideProjects
elementClass=Project
...
inverse-foreignkey field-ref=employeeId /
query language=oql
queryString=project.startDate.year 2000 and project.org emp.org
/
/collection-descriptor
One of the reasons that I prefer a Builder to a Refiner is that I have
relationships which don't involve FK's at all, so I'd like a way to
express those and never get any of the default Criteria in there. But
maybe it's sufficient to use a refinement approach, and make the FX spec
optional in repository.xml if there's a query. That way if I have FK's,
I can refine; if there aren't FK's, then I can just start from scratch.
-steve
From: Jakob Braeuchi [EMAIL PROTECTED]
hi steve,
what i miss in this approach is the operation (=, , like, between etc.) .
as far as i understand your proposal, the operation and the whole logic
is dependent of the query-builder.
this makes it quite easy for us to implement it in ojb, but it moves
the burden of implementation to the user. especially when you think of
accessing the 'originator' object as bill pointed out.
as there are lots of possibilities for query-constraints, i'm not sure
whether we'll be able to provide the most useful ones (from a user's
point of view). on the other hand your approach provides all the
flexibility one might need...
imo we should just provide a standard query-restrictor using static
parameters and operations for those who need simple restrictions only.
just my 0.02 chf
jakob
sclark wrote:
Here's an idea on the collection restriction discussion. How about something
like this:
/**
* Interface implemented by classes which are used to create a custom
* query for the contents of a collection property, when the usual
* fk/pk approach is insufficient.
*/
interface org.apache.ojb.broker.query.QueryBuilder
/** Build the query to retrieve the specified collection property */
Query buildQuery(Object obj, ClassDescriptor cld, CollectionDescriptor
cds);
}
class PersistenceBrokerImpl {
private void retrieveCollection(...) {
if (cds.getQueryBuilder() != null)
{
fkQuery = cds.getQueryBuilder.buildQuery(obj, cld, cls);
}
else if (cds.isMtoNRelation())
{
fkQuery = getMtoNQuery(obj, cld, cds);
}
else
{
fkQuery = getForeignKeyQuery(obj, cld, cds);
}
}
}
Then in my app I would write something like this:
class gov.doi.cap.ojb.query.BuildProjectsQuery implements QueryBuilder { ... }
collection-descriptor
name=projects
elementClass=gov.doi.cap.ojb.dataobjects.Project
...
query class=gov.doi.cap.ojb.query.BuildProjectsQuery
attribute
attribute-name=earliestStart
attribute-value=1999
/
attribute
attribute-name=latestStart
attribute-value=2001
/
/query
/collection-descriptor
This would allow great flexibility in the specification of the collection
RE: cvs build.xml checkj2ee.classes
Yuji, I had just posted this to dev list: Thomas, Was having a problem with init not being run when doing an ant jar-debug. Need to prepare first, which forces init or else depend on init in main. Also includes previous posted change to move user.home/build.properties ahead of build.properties. Ant properties are immutable. Thanks! Andy Index: build.xml === RCS file: /home/cvspublic/db-ojb/build.xml,v retrieving revision 1.72 diff -r1.72 build.xml 11d10 property file=build.properties/ 12a12 property file=build.properties/ 185c185 target name=main depends=checkj2ee.classes, prepare, preprocess --- target name=main depends=prepare, checkj2ee.classes, preprocess -Original Message- From: Yuji Shinozaki [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 26, 2003 2:56 PM To: OJB Users List Subject: cvs build.xml checkj2ee.classes It looks like the current CVS version of build.xml is slightly broken. For example, the 'junit' target depends on 'main' which checks on the setting of j2ee.classes. However, the j2ee.classes property is set in the 'init' target which not a dependency of neither 'checkj2ee.classes' nor 'main'. So, it will always fail. So, for example, the 'junit' target fails because j2ee.classes hasn't had a chance to run. yuji Yuji ShinozakiComputer Systems Senior Engineer [EMAIL PROTECTED] Advanced Technologies Group (804)924-7171 Information Technology Communication http://www.people.virginia.edu/~ys2nUniversity of Virginia - 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: Bug in PersistenceBroker.getCount() ?
hi scott,
i just did some tests with proxied m:n association where getCount() is
called. i changed the test-classes to have a difference between
column-name and attribute-name. so far everything was ok.
the attribute-name will be translated into column-name by the
SqlGenerator., so there should be no need to specify it in getCount().
jakob
Scott Howlett wrote:
I just changed my database schema such that one of my tables now has a
primary key field whose name is different than the column name in the
database.
Things worked OK in general until I referenced the table from another
table via an M:N association. I then got an SQL exception complaining
that I was trying to access the table using the field name, not the
column name.
I think I've traced the problem to PersistenceBrokerImpl.getCount(Query)
- in this routine a report query is made, but it's being populated with
attribute names, not column names. The offending lines of code:
for (int i = 0; i pkFields.length; i++)
{
if (query.isDistinct())
{
columns[i] = count(distinct + pkFields[i].getAttributeName()
+ );
}
else
{
columns[i] = count( + pkFields[i].getAttributeName() + );
}
}
Should the above getAttributeName() calls should be replaced with
getColumnName() instead?
Regards,
Scott Howlett
-
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: Question re prefetched relationsbips
hi mark, prefetching currently works only for one level . the prefetcher looks for a relationship named allb.singlec in A.class in your sample. the query criteria has no effect on prefetching. i'm not sure whether deep prefetching is really useful. in your sample deep prefetching would return all Bs including all Cs for the Bs. hth jakob Mark Rowell wrote: Hi Does anyone know if prefetched relationships can reach more than one layer of references/collections from an class being queried? E.g. If I have a class A that I an querying and it has a 1:m relationship with some class B, with the relationship defined by the name allb, and then each B has 1 1:1 relationsbip with another class C, with the relationship called singlec, is the following supposed to work: Criteria criteria = new Criteria(); // configure the criteria ... // add prefetched relationships criteria.addPrefetchedRelationship(allb); criteria.addPrefetchedRelationship(allb.singlec); Query q = QueryFactory.newQuery( A.class, criteria); I can get the single layer if indirection (e.g. criteria.addPrefetchedRelationship(allb)) to work, but when I try the above I get an error message from OJB saying that it cant find the relationship allb.singlec. One thing to not is that I can specify query criteria on this 2 level relationship i.e. criteria.addEqualTo(allb.singlec.somefield, test value); where somefield is a field in the class C. Regards, Mark Rowell Mark Rowell CreditTrade T: +44 (020) 7400 5078 M: mailto:[EMAIL PROTECTED] CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person. It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information. Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrades judgement at the time of compiling the data and is subject to change. CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email. The content of this email is not intended as an offer or solicitation for, or recommendation of, the purchase or sale of any financial instrument, or as an official confirmation of any transaction, and should not be construed as investment advice. - 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: Bug in PersistenceBroker.getCount() ?
Hi Jakob,
You're right. I traced my problem further to a different point in OJB
where I do believe there is a problem (see my followup message).
Thanks,
Scott
-Original Message-
From: Jakob Braeuchi [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 26, 2003 3:45 PM
To: OJB Users List
Subject: Re: Bug in PersistenceBroker.getCount() ?
hi scott,
i just did some tests with proxied m:n association where getCount() is
called. i changed the test-classes to have a difference between
column-name and attribute-name. so far everything was ok.
the attribute-name will be translated into column-name by the
SqlGenerator., so there should be no need to specify it in getCount().
jakob
Scott Howlett wrote:
I just changed my database schema such that one of my tables now has a
primary key field whose name is different than the column name in the
database.
Things worked OK in general until I referenced the table from another
table via an M:N association. I then got an SQL exception complaining
that I was trying to access the table using the field name, not the
column name.
I think I've traced the problem to
PersistenceBrokerImpl.getCount(Query)
- in this routine a report query is made, but it's being populated with
attribute names, not column names. The offending lines of code:
for (int i = 0; i pkFields.length; i++)
{
if (query.isDistinct())
{
columns[i] = count(distinct + pkFields[i].getAttributeName()
+ );
}
else
{
columns[i] = count( + pkFields[i].getAttributeName() + );
}
}
Should the above getAttributeName() calls should be replaced with
getColumnName() instead?
Regards,
Scott Howlett
-
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: Report queries on extents
hi mark,
i haven't run your testcase yet, but i think i found the problem.
the 'columns' you look for in your report-query should be
attribute-names NOT database-columns-names.
in your case 'pk' instead of 'PK'. attribute-names will be translated
into database-column-names by the SqlGenerator and will be prefixed with
a table alias (pk - A1.PK).
if you use database-column-names in the query the SqlTranslator cannot
find field-definitions matching those names and passes them unmodified
to the sql-string (no alias added: PK - PK).
imo we should improve the docs to clearly show the difference between
database-column-names and attribute-names :)
Mark Rowell wrote:
Jakob
I have a test case to show my problem
public void testReportQuery() {
testDeleteContractVersionEffectiveness();
createTestData();
Query query = QueryFactory.newReportQuery(Version.class, new
String[]{PK,contract.PK,contract.contractValue1}, null, false);
Iterator iter = broker.getReportQueryIteratorByQuery(query);
int rowCount = 0;
while ( iter.hasNext() ) {
rowCount++;
}
assertTrue(Expected to get + COUNT + rows in the report query.
Got + rowCount + instead., rowCount == COUNT);
}
Add it to the ContractVersionEffectivenessTest class. I had to chage the
primary key column names to PK from pk in
reposotory_junit.xml for the three mappings involved thus:
!--
Definitions for contract-version-effectiveness testing
Contract-Version-Effectiveness is a common model in business
see martin fowler's pages on temporal patterns.
--
class-descriptor
class=org.apache.ojb.broker.Contract
table=Contract
field-descriptor
name=pk
column=PK
jdbc-type=VARCHAR
primarykey=true
autoincrement=false
/
field-descriptor
name=contractValue1
column=contract_value1
jdbc-type=VARCHAR
/
field-descriptor
name=contractValue2
column=contract_value2
jdbc-type=INTEGER
/
field-descriptor
name=contractValue3
column=contract_value3
jdbc-type=VARCHAR
/
field-descriptor
name=contractValue4
column=contract_value4
jdbc-type=TIMESTAMP
/
field-descriptor
name=fkToRelated
column=fk_to_related
jdbc-type=VARCHAR
/
reference-descriptor
name=relatedToContract
class-ref=org.apache.ojb.broker.RelatedToContract
foreignkey field-ref=fkToRelated/
/reference-descriptor
/class-descriptor
class-descriptor
class=org.apache.ojb.broker.RelatedToContract
table=RelatedToContract
field-descriptor
name=pk
column=PK
jdbc-type=VARCHAR
primarykey=true
autoincrement=false
/
field-descriptor
name=relatedValue1
column=relatedValue1
jdbc-type=VARCHAR
/
field-descriptor
name=relatedValue2
column=relatedValue2
jdbc-type=INTEGER
/
field-descriptor
name=relatedValue3
column=relatedValue3
jdbc-type=TIMESTAMP
/
/class-descriptor
class-descriptor
class=org.apache.ojb.broker.Version
table=Version
field-descriptor
name=pk
column=PK
jdbc-type=VARCHAR
primarykey=true
autoincrement=false
/
field-descriptor
name=versionValue1
column=version_value1
jdbc-type=VARCHAR
/
field-descriptor
name=versionValue2
column=version_value2
jdbc-type=INTEGER
/
field-descriptor
name=versionValue3
column=version_value3
jdbc-type=TIMESTAMP
/
field-descriptor
name=fkToContract
column=fk_to_contract
jdbc-type=VARCHAR
/
reference-descriptor
name=contract
class-ref=org.apache.ojb.broker.Contract
foreignkey field-ref=fkToContract/
/reference-descriptor
/class-descriptor
class-descriptor
class=org.apache.ojb.broker.Effectiveness
table=Effectiveness
field-descriptor
name=pk
column=PK
jdbc-type=VARCHAR
primarykey=true
autoincrement=false
/
field-descriptor
name=effValue1
column=eff_value1
jdbc-type=VARCHAR
/
field-descriptor
name=effValue2
column=eff_value2
jdbc-type=INTEGER
/
field-descriptor
name=effValue3
column=eff_value3
jdbc-type=TIMESTAMP
/
field-descriptor
name=fkToVersion
column=fk_to_version
jdbc-type=VARCHAR
/
reference-descriptor
name=version
class-ref=org.apache.ojb.broker.Version
foreignkey field-ref=fkToVersion/
/reference-descriptor
/class-descriptor
!-- end mappings for contract-version-effectiveness --
If I use the field names in the report query (e.g. lower case 'pk') if works
fine. Using upper case values (e.g. 'PK')
and the database
OJB test failures
Armin, Looks like the test case ConvertedKeyReferenceTest might be broken. Lines 69 and 90 test for pk of ConversionReferrer being converted. If you look at the repository_junit.xml the pk field for ConversionReferrer does not have a conversion attribute. Also, neither ConvertedKeyReferenceTest nor FeildConversionForeigenKeyTest cover the case where key conversion is not happening for primary key for an object that is created. Think this was broken by change in rev 1.12 of Identity. In ConvertedKeyReferenceTest there is a case covering this issue. Not sure why it dosen't pick up the failure, but one theory is the nature of the test. The class TestInt2IntConverter flip flops values. It might better to do destructive but predictable damage to the value, rather than a flip flop. Flip flop will only really detect failure to convert in one direction, not both! Another strategy to test might be to force a class cast exception if conversion doesn't occur. I do know I need to patch Identity for the normal case of CRUD for an object with a pk that requires conversion. What I don't know is what bad side effects this causes. I think cleaning up the test cases first would help to find out. Looking for input. If you think it is worthwhile, I can come up with a test for PK conversion that will detect bi-directional failure. Just uncertain what the scenario is for reliably testing double conversion. Not sure if the test in ConvertedKeyReferenceTest for this is correct. Finally, would be nice to rename the file FieldConversionForeigenKeyTest to FieldConversionForeignKeyTest. It is mispelled. Let me know what you think. Will be glad to tackle this if you like. Index: Identity.java === RCS file: /home/cvspublic/db-ojb/src/java/org/apache/ojb/broker/Identity.java,v retrieving revision 1.14 diff -r1.14 Identity.java 195,196c195 // BRJ: do not convertToSql this.pkValues = targetBroker.serviceBrokerHelper().getKeyValues(cld, objectToIdentitify,false); --- this.pkValues = targetBroker.serviceBrokerHelper().getKeyValues(cld, objectToIdentitify); -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 19, 2003 6:32 AM To: OJB Developers List Subject: [OJB test failures] some really nasty bugs Hi all, I add some new test cases posted by Users (thanks Charles, Oliver and all I forget) and do some modifications to point out the problems (I hope so;-)). 1. UserTestCases Test testImplicitLocking() fail when implicit locking was set to 'false', the test pass when implicit locking was 'true'. The test change the 'useImplicitLocking' property to 'false' to simulate the situation. 2. FieldConversionForeignKeyTest/ConvertedKeyReferenceTest This was the really nasty bug! Both test cases use field conversions. It seems that in some cases PK fields are not converted. For example in StatementManager#bindSelect(...) method, the given Identity object seems to wrap unconverted pk values, when I do a field conversion in this method all seems ok, but now in some cases the field conversion was done twice (ConvertedKeyReferenceTest) on the same values. This is tragic when using a field conversion like TestIntToIntConverter. I think one part of the problem could be Identity, because it is possible to make Identity instances with converted pk values and without! new Identity(Object objectToIdentitify, PersistenceBroker targetBroker) -- without conversion new Identity(Class aClass, Object[] CONVERTEDpkValues) -- with converted pk valuse Any suggestions? regards, Armin - 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]
Am I using reverse-db2 right?
Hello, I've read the archives so know there are lots of problems with reverse-db2 right now. So my question isn't really about a bug or anything, I just want to know if I'm trying to use it right before I give up (I don't see any doc on usage). I want to create a new OJB repository from an existing database. I run reverse-db2, open my database, it goes through and finds and displays all the objects fine. Then I do file - new ojb repository and it opens a new window. I'm kind of at a loss on what to do from there. The tried dragging a few objects from my database window to my new repository window and it always ends up in an error in my console saying it can't find that object class (of whatever object I was dragging)... java.lang.ClassNotFoundException: mytable at java.net.URLClassLoader$1.run(URLClassLoader.java:198) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:186) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265) at java.lang.ClassLoader.loadClass(ClassLoader.java:262) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:322) snip Am I doing it right, and I'm just hitting another bug or is there another way to do this? I'm using PostgreSQL 7.2 and latest OJB from CVS. Thanks!! - Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more
Limiting a number of rows returned
Hi, Does anyone know how to limit a number of rows returned from database using OJB? Most of the database engines implement custom keywords to limit a number of rows for select statement (top, limit, rownum () .), OJB Query interface has methods in it to set EndAt and StartAt indexes as well as the size of resultset returned but setting them doesn't really help. The database engine I'm using is HSQLDB. Thank, you in advance. Max.
RE: Limiting a number of rows returned
I implemented this functionality for PostgreSQL.
I subclassed SqlGeneratorDefaultImpl to provide the functionality and
then pointed to my subclass in OJB.properties.
My OJB.properties entry is:
SqlGeneratorClass=PostgreSqlStatementGenerator
My subclass code is:
import org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl;
import org.apache.ojb.broker.metadata.ClassDescriptor;
import org.apache.ojb.broker.platforms.Platform;
import org.apache.ojb.broker.query.Query;
public class PostgreSqlStatementGenerator extends
SqlGeneratorDefaultImpl {
public SqlStatementGenerator(Platform pf) {
super(pf);
}
public String getPreparedSelectStatement(
Query query,
ClassDescriptor cld) {
String result = super.getPreparedSelectStatement(query, cld);
return addOffsetLimit(query, result);
}
public String getSelectStatementDep(Query query, ClassDescriptor
cld) {
String result = super.getSelectStatementDep(query, cld);
return addOffsetLimit(query, result);
}
private String addOffsetLimit(Query q, String stmt) {
int startIndex = q.getStartAtIndex();
int endIndex = q.getEndAtIndex();
if (endIndex 0) {
if (startIndex 0 || startIndex = endIndex) {
startIndex = 0;
}
stmt += LIMIT + (endIndex - startIndex);
}
if (startIndex 0) {
stmt += OFFSET + startIndex;
}
return stmt;
}
}
Hope that helps,
Scott Howlett
-Original Message-
From: Max Vesely [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 26, 2003 10:27 PM
To: [EMAIL PROTECTED]
Subject: Limiting a number of rows returned
Hi,
Does anyone know how to limit a number of rows returned from database
using OJB?
Most of the database engines implement custom keywords to limit a number
of rows for select statement (top, limit, rownum () .), OJB Query
interface has methods in it to set EndAt and StartAt indexes as well as
the size of resultset returned but setting them doesn't really help. The
database engine I'm using is HSQLDB.
Thank, you in advance.
Max.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
