Re: Antwort: Java DB Mapper
Hans Novak escribió: Mario Curcija schrieb: Hi Hans, just download latest OJB release (1.0.4) and look for the "profile" directory. You should find all ".profile" files in it. Here is derby.profile in SVN. http://svn.apache.org/viewvc/db/ojb/tags/OJB_1_0_4/profile/derby.profile?view=markup Hi, thanks. now i find it too ;) last (off topic) question: where can i find a "howto" for use the java db ? Here is the link to derby manuals: http://db.apache.org/derby/manuals/index.html#docs_10.3 (how can i install it - (for development / customer), how can i browse thru the data like in mysql) For data browsing, I use: http://squirrel-sql.sourceforge.net/ Hope this helps. Best Regards, Antonio Gallardo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Concurrent Users
Vagula escribió: Hi, Yes I need info about concurrent connections. What are the settings to be in OJB.properties? Look in [1] for persistence broker pool properties. Inside the file each property is described. Best Regards, Antonio Gallardo [1] http://db.apache.org/ojb/OJB.properties.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Concurrent Users
Hi Vagula, Would you explain more your idea? If you are talking about concurrent connections to the database, OJB has database connection pool, which can be configured in the OJB.properties. Best Regards, Antonio Gallardo. Vagula escribió: Hi All, How can I handle concurrent users using OJB? TIA. Regards, Vagula It may be more worthwhile, to find out what is right than-who is right. CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS*** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB Dependency breakdown
Hi Mike, Carlos sent our pom descriptor for ojb. See more comments between lines Mike Perham escribió: Here's my first pass at determining how OJB 1.0.4 uses the various dependencies. Basically I just moved each package out of lib and ran compile/test to see what failed and how. Comments welcome. The second line for each is my suggested scope/optional dependency setting in the OJB Maven 2 POM, e.g: antlr antlr 2.7.5 compile true Hope this helps others. mike === antlr-2.7.5.jar Used to parse JDOQL Compile/Optional compile time only dependency. Not needed for runtime. commons-beanutils-1.7.0.jar Uses DynaBean and PropertyUtils Compile/Required, consider forking code to remove this dep? I think it is required. commons-betwixt-0.8-dev.jar Unknown usage Remove? Runtime/Optional, no compilation or test failures without it yes. commons-digester-1.7.jar Used by ant DdlUtils support Compile/Optional commons-pool-1.2.jar Used with DBCP connection pooling Compile/Optional, J2EE container should perform pooling at runtime Optional, it depends on OJB configuration. commons-transaction-1.1.jar Used by OJB's broker.locking package Compile/Required jakarta-regexp-1.3.jar Used by reversedb mapping tool Compile/Optional jcs.jar One of a number of caching impls Compile/Optional prevayler.jar Object database, unknown usage Runtime/Optional? It is optional. Needed if you choose prevayler as you DB. village-2.0.jar Used with Torque to generate DDL, no compile/test failures without it Runtime/Optional? Optional, not needed at runtime. ut's used only by torque. Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Calling a Stored Procedure through OJB
hi, Googling for: OJB stored procedure returns: http://db.apache.org/ojb/docu/howtos/howto-work-with-stored-procedures.html Best Regards, Antonio Gallardo. Anjishnu Bandyopadhyay escribió: Hi all, I want to call an Oracle Stored Procedure (SP) through OJB (say, via the PersistenceBroker object). Is there a way I can do it? Thanks for your time. With best regards, Anjishnu. CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS*** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: newbie problems
Dmitry Litvintsev escribió: Thank you Armin, Please educate me a bit, cause I am a bit perplexed by your mail. You say OJB does not work well w/ JDO, use ODMG or PB OK, I understand that. then you say: If you want to use JDO, please have a look at JPOX or Speedo (or other JPOX is a implementation of JDO, isn't it? So can I use OJB w/ JPOX then? Or should I just use JPOX ? (this indicates my confusion at what exactly OJB does on the top of JDO). Please help me out. Hi Dmitry, We cannot use OJB w/ JPOX. Basically, the JDO support in OJB works only with Sun JDO 1.0.1 [1]. If you want to stay in "Apache home", you should try Apache JDO wich is working on a final release of a "JDO 2" version. Best Regards, Antonio Gallardo. [1] http://java.sun.com/products/jdo/ [2] http://db.apache.org/jdo/ On Wed, 19 Apr 2006, Armin Waibel wrote: Hi Dmitry, I don't know what's going wrong when running the tutorial (seems that Product.class was correctly enhanced by the JDO enhancer). But I wouldn't recommend OJB's JDO 1.0-api implementation for production environments. The PB-api and ODMG-api are stable and ready for production use http://db.apache.org/ojb/status.html If you want to use JDO, please have a look at JPOX or Speedo (or other projects) http://www.jpox.org/index.jsp http://speedo.objectweb.org/ regards, Armin Dmitry Litvintsev wrote: Hi, I am developing a java application and I am considering OJB technology to store objects' states seamlessly in the PostgreSQL database. In short I am failing to get tutorial5 up and running. I followed instructions on this link: http://db.apache.org/ojb/docu/tutorials/jdo-tutorial.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: don't need all columns
Hi, You should use a ReportQuery [1]. Best Regards, Antonio Gallardo. [1] http://db.apache.org/ojb/docu/guides/query.html#Report+Queries Abid Hussain escribió: Hi everybody, I'm quite a newbie in OJB, so maybe I have overlooked something. In most cases I don't need all colums of a table when I do a query. So, how do I tell OJB not to retrieve all 25 (e.g.) columns of a table but only the ones I need? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5, JNDI, Perm Gen Memory leak
hi, Seems like an class loader issue. Can you check if there are not older ojb.jar in your classpath loaded before the ojb 1.0.4? Best Regards, Antonio Gallardo. Rick Roman wrote: I upgraded to the new db-ojb-1.0.4 which has the method PersistenceBrokerFactoryFactory.instance().shutdown(); This results in exception: [ERROR] mffweb] - Exception sending context destroyed event to listener instance of class org.mff.web.listener.CleanupListener org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V>java.lang.NoSuchMethodError: org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V at org.mff.web.listener.CleanupListener.contextDestroyed(CleanupListener.java:59) Still have memory leak or (I suppose more accurtately, failure to clean up resources). Anyone have any ideas or has anyone ever actually been able to avoid this problem or am I just stuck with it? Armin Waibel wrote: Hi Rick, Rick Roman wrote: Sorry to be dense but can you send me the link to cvs for revision 1.4.2.2 of PersistenceBrokerFactoryIF? I'm having trouble locating it. Think this will not work, because the changes will affect other classes too. http://www.mail-archive.com/ojb-dev@db.apache.org/msg01553.html I recommend to use the latest from OJB 1.0.x branch (OJB_1_0_RELEASE branch, trunk is unstable 1.x). The 1.0.x branch is 95% stable (the test-suite show some odmg-api specific test failures, will be fixed soon). regards, Armin Ilkka Priha wrote: Rick, It was introduced in revision 1.4.2.2 of PersistenceBrokerFactoryIF (25/07/05), so it's available only in the cvs version of OJB, but hopefully quite soon also as 1.0.4-rc. -- Ilkka /** * Shutdown method for OJB, kills all running processes within OJB - after * shutdown OJB can no longer be used. * * This method is introduced to solve hot/redeployment problems (memory leaks) caused by * the usage of [EMAIL PROTECTED] ThreadLocal} instances in OJB source and the reuse of threads * by the container (e.g. servlet- or ejb-container). */ public void shutdown(); Rick Roman wrote: Hi Ilkka, shutdown() does not appear to be a method of PersistenceBrokerFactoryFactory.instance(). Is there a patch with this available? Ilkka Priha wrote: Hi Rick, Have you tried this one, it alone should do the job. PersistenceBrokerFactoryFactory.instance().shutdown(); -- Ilkka Rick Roman wrote: Update: From other threads, I have tried using a contextDestroy listener to run: PersistenceBroker broker = PersistenceBrokerFactory.defaultPersistenceBroker(); broker.clearCache(); broker.close(); PersistenceBrokerFactory.releaseAllInstances(); ConnectionFactoryFactory.getInstance().createConnectionFactory().releaseAllResources(); PersistenceBrokerThreadMapping.shutdown(); MetadataManager.getInstance().removeAllProfiles(); and the leak still persists. Rick Roman wrote: I am using OBJ to access PostgreSQL via a JNDI datasource. My problem is that every time I reload my application context, I get a big jump in Tomcat Perm Gen memory. After a several reloads, tomcat eventually crashes with an out of memory error. I believe this has to do with my OBJ configuration as I am able to access the datasource without OBJ and I don't see the problem. The memory leak problem is a known issue, discussed in detail here: http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669 In short, the problem is that "if any object that is loaded by the system or container classloader (StandardClassLoader in tomcat) still has a reference to the application class loader or any object loaded by it, the class loader will not be garbage collected. In that case, all the class objects and every object referenced by a static field in any of the classes will not be garbage collected." Does anyone know how I can get rid of this behavior? (repository.xml, OBJ.properties below) repository.xml ignoreAutoCommitExceptions="false" > class="org.apache.ojb.broker.cache.ObjectCacheDefaultImpl"> attribute-value=""/> attribute-value="true"/> attribute-value="0"/> className="org.apache.ojb.broker.util.sequence.SequenceManagerNextValImpl"> OBJ.properties repositoryFile=repository.xml useSerializedRepository=false serializedRepositoryPath=. PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl maxActive=256 maxIdle=-1 maxWait=2000 timeBetweenEvictionRunsMillis=-1 minEvictableIdleTimeMillis=100 whenExhaustedAction=0 ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl
Re: NullPointerException in SqlQueryStatement OJB 1.0.3
Jakob Braeuchi wrote: hi antonio, this known-issue is documented in the release notes (at least it is in the soon-to-be-released 1.0.4). Thanks! :-) Best Regards, Antonio Gallardo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NullPointerException in SqlQueryStatement OJB 1.0.3
Jakob Braeuchi wrote: hi andy, i can reproduce the npe using your testcase. the npe happens in the SqlQueryStatement for the sub-query. this is imo a known issue because sub-queries are not yet extent-aware. Hi Jakob! thanks for reviewing the testcase. Can we add it to just don't forget that this needs to be addressed. Makes sense? Can we document it? Best Regards, Antonio Gallardo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NullPointerException in SqlQueryStatement OJB 1.0.3
Andy Malakov wrote:
I will add a test for this bug, how can we reproduce the NPE, how does
the query look like?
Here it is. May be you will spot something wrong in it:
SELECT * FROM USERS WHERE PK IN (
SELECT USER_FK
FROM ITEMS
WHERE RETURN_DATE BETWEEN yesterday AND tomorrow
)
Criteria innerCriteria = new Criteria ();
innerCriteria.addBetween("returnDate", YESTERDAY, TOMORROW );
ReportQueryByCriteria innerQuery = QueryFactory.newReportQuery (Item.class,
innerCriteria);
innerQuery.setAttributes (new String [] { "userFk" });
Criteria outerCriteria = new Criteria ();
outerCriteria.addIn ("pk", innerQuery);
QueryByCriteria outerQuery = QueryFactory.newQuery (User.class,
outerCriteria);
where Item is abstract class with extent.
Armin, I will send you entire test case by personal mail.
Andy, if you want to contribute the tescase, please add the code as an
attachment to a JIRA issue. It is the way to go if you want to
contribute code for legal reasons. ;-)
Best Regards,
Antonio Gallardo.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: getCollectionByQuery
k jee wrote: Hi I am trying to use getCollectionByQuery and I want to get the collection that is returned from this to be different than the object that I pass to the criteria. Is this possible? Can someone give me an example on how to do this? http://db.apache.org/ojb/docu/guides/query.html#Report+Queries Best Regards, Antonio Gallardo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Group by having causes "inner hasNext was false" error
Bertrand Delacretaz wrote: Hi, I'm using a GROUP BY HAVING query (using addGroupBy and setHavingCriteria to a QueryByCriteria), and depending on the data I get an "inner hasNext was false" error. IIUC the problem is due to the SELECT COUNT [2] query used by OJB to find out how many objects to retrieve, which in some cases finds more objects that the main query retrieves, causing the RsIterator to fail as it believes there are more objects to retrieve but finds the end of the result set. The main query does a GROUP BY A0.DOCUMENT_ID HAVING count(*) >= 1 Hi: I think the clausule : [HAVING count(*) >= 1 ] creates unnecessary processing. Best Regards, Antonio Gallardo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB-JDO why sequence increment in retrieve
On Mar, 10 de Mayo de 2005, 12:28, Alessandro Vincelli dijo: > Hi > > I have a problem to include db-ojb1.0.3 > in Cocoon 2.1.7 build with jdk.1.5 > Can I compile db-ojb1.0.3 with jdk.1.5 and include this in Cocoon? I guess yes. I will try to add this to the cocoon svn today night. Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB-JDO why sequence increment in retrieve
On Lun, 9 de Mayo de 2005, 2:45, Alessandro Vincelli dijo: > I use db-ojb-1.0.1 with cocoon 2.1.7 > > Can i try the new latest release with cocoon? Yep. > Thanks a lot Gallardo > > I use with great satisfaction Druid. I have read all what you have > made on OJB/JDO/CForms. :-) I am glad to hear that! Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB-JDO why sequence increment in retrieve
Hi: Please provide the OJB version you use. AFAIK, it was already fixed for non JDO API's. Best Regards, Antonio Gallardo On Lun, 9 de Mayo de 2005, 18:15, Alessandro Vincelli dijo: > I use this simple code to retrieve row, > but after this code the db sequence of Utenti table is autoincrement. > Why? > Thanks,Ale > > > //1. Get the PersistenceManager > PersistenceManager persistenceManager = > jdo.getPersistenceManager(); > Utenti e = new Utenti(); > e.setId_utente(bean.getId_utente()); > PersistenceBroker broker = > PersistenceBrokerFactory.defaultPersistenceBroker(); > Identity oid = new Identity(e, broker); > Utenti b = new Utenti(); > //2. start transaction > persistenceManager.currentTransaction().begin(); > // 3. Get the Object based on the primary key > b = (Utenti) persistenceManager.getObjectById(oid, false); > // 4. Copy data to bean > copyData(b, bean); > // 5. End transaction > persistenceManager.currentTransaction().commit(); > > - > 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: Mandragora: a new project based on Ojb
Hi Aleesandro: The project sounds interesting. Some advises: The Apache incubator is the entry gateway for new projects: http://incubator.apache.org/ Please also read general notes about new projects http://jakarta.apache.org/site/newproject.html Best Regards, Antonio Gallardo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Crash while retrieving Results from a Reportquery and query.setEndAtIndex()
On Lun, 14 de Febrero de 2005, 14:23, Christoph Hermann dijo:
> Jakob Braeuchi schrieb:
>
> Hello,
>
>> what do you mean by 'crash' ? could you please post the exception.
>
> hmm of course, sorry that i forgot this :/
>
> The Exception is:
>
> org.apache.cocoon.ProcessingException: Failed to execute pipeline.:
java.lang.RuntimeException: java.lang.RuntimeException:
> org.apache.avalon.framework.CascadingRuntimeException:
> "file:/usr/local/jakarta-tomcat-4.1.31/webapps/cocoon_2.1.6/samples/guschtel/nymphoon/flow/authentication.js",
line 318: uncaught JavaScript exception: at displayMenu
> (file:/usr/local/jakarta-tomcat-4.1.31/webapps/cocoon_2.1.6/samples/guschtel/nymphoon/flow/authentication.js,
Line 318):
>
> java.util.NoSuchElementException: Could not obtain next object: inner
hasNext was false
>
> 317: while ( it.hasNext() ) {
> 318: var o = it.next(); // crashes here
> 319: suggestions.add(o);
> 320: }
Thanks. This is inside Cocoon Flow. Seems that OJB has nothing to do in
this case. Please send more code of this Javascript. I would recommend to
move this business code to a java code and call it from your Flow
function. There are some small incompatibilities while manipulating Java
object inside Javascript.
I have interest in know how is declared "it". Which kind of object it is.
Best Regards,
Antonio Gallardo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: remove table alias in generated SQL?
On Lun, 24 de Enero de 2005, 14:01, Thomas Dudziak dijo: > Of course there is a limit, but it might at least be useful to support > > * read-expressions containing database-supplied functions (e.g. > count() ) possibly working on multiple columns > > * write-expressions containing multiple fields of the same class > descriptor and/or columns > > Don't know where to put the limit, so how about supporting simple > expressions for now, where variables like $FirstName are resolved > against the current class descriptor which leads to the expansion into > a (aliased) column name, and the resulting string is used as-is in the > select/insert/update statement ? Each database supports diferents kind of expressions. IMHO, this kind of expresions are used mainly for reporting => support for them in ReportQueries. Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: remove table alias in generated SQL?
On Lun, 24 de Enero de 2005, 8:32, Bobby Lawrence dijo: > Not having an alias would allow you to use functions and string literals. > You could specify a string literal in the field-descriptor like this: > > > This would give you the same value for every class instance, which might > not seem that useful at first, but this is exactly what I needed in my > project for a brief time. At the time, I was expecting values from the > database where the field did not exist yet and I needed something to test. Is posible to test for null? > You could also specify functions in the field-descriptor like this: > > If using an Oracle database, this would concatenate the first and last > names to give you a whole name. Could be used in a ReportQuery if we make it resolve more than 1 field in a expresion. > > Another example on concatenation w/ Oracle without using the function: > Works in PostgreSQL too, again the solution is using a ReportQuery that solves multiplefields in one expresion. > All of these should be possible if OJB didn't use table aliases in its > generated SQL statements. While the theory indicates that each field in the database must have a unique name. In the practice, we found that in some databases, the users choose same names for fields in diferentables. Sample: table1.ID table2.ID the same field name "ID" should be resolved and this is why I think OJB choosed to use SQL table alias to resolve this names. > What IS the benefit of using an alias? Not being a big fan of SQL alias, but what I understand: 1-This is convenient when you want to obtain information from two separate tables (the technical term is 'perform joins'). The advantage of using a table alias when doing joins is readily apparent when we talk about joins. 2- Generate shorter queries: SELECT from mylongnametable.fieldA, mylongnametable.fieldB FROM mylongnametable; vs. SELECT from A0.fieldA, A0.fieldB FROM mylongnametable A0; Hope this helps, Best Regards, Antonio Gallardo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: remove table alias in generated SQL?
Hi: Alll your recommendations could be easily addressed with ReportQueries allowing resolving expresions with more than one field. Best Regards, Antonio Gallardo On Lun, 24 de Enero de 2005, 8:32, Bobby Lawrence dijo: > Not having an alias would allow you to use functions and string literals. > You could specify a string literal in the field-descriptor like this: > > > This would give you the same value for every class instance, which might > not seem that useful at first, but this is exactly what I needed in my > project for a brief time. At the time, I was expecting values from the > database where the field did not exist yet and I needed something to test. > > You could also specify functions in the field-descriptor like this: > > If using an Oracle database, this would concatenate the first and last > names to give you a whole name. > > Another example on concatenation w/ Oracle without using the function: > > > All of these should be possible if OJB didn't use table aliases in its > generated SQL statements. > > What IS the benefit of using an alias? > > > Jakob Braeuchi wrote: > >> hi bobby, >> >> i still do not get the benefit of not using an alias. could you please >> post a sample ? >> >> jakob >> >> Bobby Lawrence schrieb: >> >>> Well - it seems that the alias is not needed. >>> If the class only goes to one table for its data, why does the table >>> need an alias? >>> If an alias was not used, you could specify string literals for a >>> column name. >>> >>> >>> Jakob Braeuchi wrote: >>> >>>> hi, >>>> >>>> ojb should always use the alias in front of the column name. if it >>>> does not, it could probably not translate the attribute name into a >>>> column name. >>>> >>>> btw: what exactly is the problem with the alias ?? >>>> >>>> jakob >>>> >>>> Vesely, Max [IT] schrieb: >>>> >>>>> Bobby, >>>>> >>>>> I was able to do it by listing field names in a ReportQuery object. >>>>> It also won't append table alias in front of the column name in >>>>> this case. >>>>> >>>>> Max. >>>>> >>>>> -Original Message- >>>>> From: Bobby Lawrence [mailto:[EMAIL PROTECTED] Sent: >>>>> Thursday, January 20, 2005 5:38 PM >>>>> To:ojb-user@db.apache.org >>>>> Subject:remove table alias in generated SQL? >>>>> >>>>> Is there a way to tell OJB to not use the table alias in front of >>>>> the column names when it generates SQL? >>>>> Currently, when you specifiy that a class comes from and a >>>>> field of that class comes from , OJB executes the following >>>>> SQL: >>>>> SELECT A0. FROM A0 >>>>> >>>>> If you can't map one class to multiple tables, I don't see why this >>>>> is necessary. >>>>> Is there any way around this? >>>>> >>>>> Instead of mapping a field to a specific column, I want to map it >>>>> to a string literal so that it always has the same value for the >>>>> class. >>>>> >>>>> Ex. >>>>> >>>>> -- Bobby >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> - >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>> >>>>> >>>>> >>>>> - >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>> >>>>> >>>> >>>> - >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > -- > > Bobby Lawrence > MIS Application Developer > > Jefferson Lab (www.jlab.org) > > Email: [EMAIL PROTECTED] > Office: (757) 269-5818 > Pager: (757) 584-5818 > > > > > > > - > 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: remove table alias in generated SQL?
On Vie, 21 de Enero de 2005, 14:48, Bobby Lawrence dijo: > SELECT FROM (SELECT * FROM ) > vs. > SELECT * FROM WHERE IN (SELECT FROM > WHERE = 'aValue') > > If so, the table alias would still not be needed because the columns are > still only coming from one table Not in all cases. Is posible to write: SELECT * FROM WHERE IN ( SELECT FROM WHERE = 'aValue' ) Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: remove table alias in generated SQL?
On Vie, 21 de Enero de 2005, 12:23, Bobby Lawrence dijo: > Well - it seems that the alias is not needed. > If the class only goes to one table for its data, why does the table > need an alias? > If an alias was not used, you could specify string literals for a column > name. Yep. But remember that we are auto-generating queries. We will need to create a more complex logic to decide if a fields needs or not an alias and IMHO this will take more time than now. I am not telling this could not be improved. Perhaps we need to make some test about it. Best Regards, Antonio Gallardo. > > > Jakob Braeuchi wrote: > >> hi, >> >> ojb should always use the alias in front of the column name. if it >> does not, it could probably not translate the attribute name into a >> column name. >> >> btw: what exactly is the problem with the alias ?? >> >> jakob >> >> Vesely, Max [IT] schrieb: >> >>> Bobby, >>> >>> I was able to do it by listing field names in a ReportQuery object. >>> It also won't append table alias in front of the column name in this >>> case. >>> >>> Max. >>> >>> -Original Message- >>> From: Bobby Lawrence [mailto:[EMAIL PROTECTED] Sent:Thursday, >>> January 20, 2005 5:38 PM >>> To:ojb-user@db.apache.org >>> Subject:remove table alias in generated SQL? >>> >>> Is there a way to tell OJB to not use the table alias in front of the >>> column names when it generates SQL? >>> Currently, when you specifiy that a class comes from and a >>> field of that class comes from , OJB executes the following >>> SQL: >>> SELECT A0. FROM A0 >>> >>> If you can't map one class to multiple tables, I don't see why this >>> is necessary. >>> Is there any way around this? >>> >>> Instead of mapping a field to a specific column, I want to map it to >>> a string literal so that it always has the same value for the class. >>> >>> Ex. >>> >>> -- Bobby >>> >>> >>> >>> >>> >>> - >>> 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] >> > > -- > > Bobby Lawrence > MIS Application Developer > > Jefferson Lab (www.jlab.org) > > Email: [EMAIL PROTECTED] > Office: (757) 269-5818 > Pager: (757) 584-5818 > > > > > > > - > 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]
Where are the Java version requirement on the website?
Hi: I tried to find the minimal Java version needed by OJB and I cannot find it on the web site. Can someone sent me the link? :-) Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] - Cocoon + OJB a success history
Hi: I found on the cocoon dev list a success history of a new website powered with Cocoon and OJB: http://issues.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=37227 The full thread is here: http://issues.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=890776 Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB vs Hibernate
Robert S. Sfeir dijo: > Brian, > Thanks for the post. The times between rc2 and 1.0, I believe, are > actually > to new PersistentFieldIntrospectorImplNew. If you're not using that, you > should and you'll see an even bigger diff. That setting can be changed in > OJB.properties > > HTH > R > > P.S. Did you post this on Hibernate list??? :-) lol. Seriously, I think it is a good idea, perhaps they can find where the problem is. I know it is OT for our list. Thanks Brian for the feedback. :-) Best Regards, Antonio Gallardo. > > > On 8/9/04 8:57 AM, "Mcgough, Brian Joseph" <[EMAIL PROTECTED]> wrote: > >> All, >> >> I just wanted to share some data points that were recently collected >> that compare OJB and Hibernate and the ability to scale with both. >> >> We had a data file with only 10,000 records in it that we needed to load >> into our database. Typically we use our batch environment, but given >> that we are a java shop now, we wanted to see if we could use java and >> our ORM tool to get the job done. >> >> We started out using Hibernate for this, and we found that we had some >> real problems. It just would not scale whether or not we were using >> transactions. We found that it would take greater than 17 hours to load >> only 7500 of the records. Obviously this is unacceptable performance, >> and so we thought to try the same thing using OJB. >> >> I am happy to report that using OJB we were able to load the whole file >> of 10,000 in under 12 minutes. >> >> In addition to this, we just recently upgraded a project from OJB 1.0 >> rc2 to OJB 1.0 and I am happy to report that for that particular project >> db performance was improve by a factor greater than 10. This is mostly >> due to the new implementation for FieldAccess. >> >> I just wanted to thank the developers for their attention to detail in >> regards to ensuring that the overhead above jdbc was minimal, and for >> all of the tests that they have written to ensure that is the case. We >> are very happy that we are still able to use ORM for this instead of >> straight jdbc, because the rest of the application is written using the >> ORM. >> >> Anyway I just wanted to share these points with the group, for those of >> you that are out there and are on the sidelines as far as which >> framework will scale better. >> >> Brian McGough >> IU - UITS - UIS - SIT >> (812) 856-4871 >> > > > > - > 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: Patch submission for cache implementations
Guillaume Nodet dijo: > Where can i send you a mail ? > I tried [EMAIL PROTECTED] but it seems > that my mail has been rejected because of the > attached file ... Perhaps you can create a bug report and attach the file. WDYT? Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patch submission for cache implementations
Guillaume Nodet dijo: > I think there are several problems with the cache implementations : > > * ObjectCacheJCSImpl > The JCS cache documentation states that it is a good > practice for performance to use strings instead of > objects for keys. As the string representation of > an Identity is unique, it modified the code to > use oid.toString() as keys instead of oid ? Now, I understand why this is so slow. We are using JCS in Cocoon and there is a lot faster. Thanks for the explanation. Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJb Blog entry, JDO and other things.
Hi Robert: Thanks for the answer. I agree with you, OJB needs to concentrate in release the so long awaited 1.0 release. We have better thing to do. BTW, I already posted again your OJB article to TSS. I hope this time they will publish it. :-) Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJb Blog entry, JDO and other things.
Robert Sfeir dijo: > Win what? :-) > > The whole thing about java and open source is choice, there is no winner. > Yes there could be more adopters, and yes some of the Hibernate stuff will > end up in EJB 3.0, but in the end EJB is EJB, and the complexity of it all > is not for every project. OJB is for every project, it's lightweight and > follows existing standards, Hibernate doesn't, and EJB 3 is a ways out. > > If EJB 3 is Hibernate, good let Hibernate go to the dogs with EJB3 and in > the end OJB will be around for people like most of us on here who really > don't want to deal with the layers EJB brings along. Hi Robert and all: I know you recently wrote an article about OJB. As you remember, I also send a post to TSS, but was never published. The reason why they decided to not publish, is obscure to me. But amazing is that, after I ranting at TSS a new Cocoon article that I posted a link few days before my public rant, was published! The OJB article never. I will try to post it again. The "win" expression is a metaphore. For some people (including me), english is not our first language and it is hard to express correctly what we think in your language. In the literal sense of "win", maybe there are no winners expressed in a cash income. I think even in OS there are winners too. ie: The Apache httpd project is a winner. It is used for more than 60% of web servers in the world and not just because it is free. And is perceived also as a winner. A winner in the same sense when you win a race in the school. You don't receive a money (or nothing) for your victory, but you are happy of that. You feel as a winner. In the same sense, I think we need to let developers know that here is a wonderful project called OJB. I think Open Source projects also need publicity (as your article) and more links to OJB in the web. I already do little efforts about that. I will be glad to see more OJB users. I have also concerns that the Open Source world is become very political. Today I hear more often hear people saying that "because of politics" things go this way. I think it damage the overall OS communities. I think that the big commercial player have a big share in that. They need to protect own products. But maybe I am wrong here. As a sample, see the votation against JDO in JCP. While we are talking about all this, I also wanted to tell that EJB3 is often perceived as a big slow and complex. In cotrast, there are many lightweight containers that already probed to be good enough in a far easier way. And that is important too. OJB have a place there too! Weeks ago, I sent a mail to jdocentral requesting for a change in the link to OJB. They had an old link there. On the mail I explained OJB developing a JDO RI. The answer received from David Jordan was: "I hope OJB becomes fully compliant with JDO soon. MANY are wanting this as an open source alternative. Many have said they will not consider the commercial offerings until such an open source implementation is also available." So we have a challenge, many people outhere is waiting for us! :-D Best Regards, Antonio Gallardo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Which release of postgresql use ?
A Leg dijo: > Which postgres release is best adapted to ojb 7.4.2, 7.3.6, 7.2.4 ? OJB is independent of the version. It uses JDBC to connect to the database. For that reason, I think you can choice any of them. Of course the lastest is the best. Also make sure to download the lastest JDBC driver from http://jdbc.postgresql.org/ Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] PostgreSQL vs. MySQL vs. Commercial DB
Hi: I found this interesting article: http://linuxtoday.com/it_management/2004042102126RVSVSW Best Regards, Antonio Gallardo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB possible bug when using automatical assignment of uniquevalues on Postgres
Martin I. Levi dijo:
> Hi Antonio:
>
> Its in our to-do list but we are mostly working on code development
> right now.
I think you can upgrade since there are not too complicated changes. BTW,
I worked without problems with PostgreSQL and RC5. As Thomas suggested
you, I think the problem is related the lack of a sequencer. Take a look
in a simple sequencer table (I don't saw a similar in your posted sample):
CREATE SEQUENCE area_seq
INCREMENT 1 MINVALUE 1 MAXVALUE 2147483647 START 1 CACHE 1;
CREATE TABLE area
(
are_idint4 not null default nextval('area_seq'),
are_name varchar(70) unique not null,
primary key(are_id)
);
-- Default Areas.
INSERT INTO area(are_name) VALUES ('area 1');
INSERT INTO area(are_name) VALUES ('area 2');
INSERT INTO area(are_name) VALUES ('area 3');
This pretty work on PostgreSQL. IN the repository.xml we found:
And the Area.java Bean is:
public class Area implements java.io.Serializable
{
private Integerare_id;
private String are_name;
}
Please note this is a very trivial sample, in fact we have more
complicated cases in our database. We have a 80 tables and more than 20
SEQUENCES in the DB and it worked fine with OJB RC5 and RC6.
Hope this help.
Best Regards,
Antonio Gallardo.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB possible bug when using automatical assignment of uniquevalues on Postgres
Hi Martin: Can you upgrade to OJB 1.0.rc6? Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any one using PostgreSQL and OJB ?
Robert S. Sfeir dijo: > Leandro Rodrigo Saad Cruz wrote: > >>I am. no problems. >> >> >> > > Ditto, no issues, use it for almost all my projects unless client can > pay for Oracle :-) Yep. PostgreSQL is my prefered choice too, even if the client can pay for Oracle or anything else. ;-) Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Most Stable OJB version
Chris Lewington dijo: > Hi all, > > I'm planning to upgrade from version 0.9.7 (yes, I know that is rather > old but with some tweaking it has mostly worked for us). Can anyone > suggest the best upgrade? Obviously the CVS head is the most up to date, > but is rc4 or rc5 a better bet for stability right now? I think the best stable is the CVS HEAD. Soon will be the 1.0 release. Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use of boolean
Hi Again ;-) Use BIT in the repository.xml: Best Regards, Antonio Gallardo Philippe Guillard dijo: > I don't know how to use boolean type in JDO, and i'm new there, if > somebody can help...It seems boolean is supported? > > - I use cocoon and downloaded jdo/jdori.jar from SUN > - In my descriptor/repository file : > jdbc-type="BOOLEAN"/> > - In java code i tried to declare Boolean and boolean > - In mysql, my column type is bool wich means tinyint(1) > - I use jdvc driver mysql-connector-java-3.0.10-stable-bin.jar > > The error is (apart from PK id=0 which is solved next lines in my code): > org.apache.ojb.jdori.sql.OjbStoreFatalInternalException: > org.apache.ojb.jdori.sql.OjbStoreManager.insert NestedThrowables: > org.apache.ojb.broker.PersistenceBrokerSQLException: SQL failure while > insert object data for class > org.apache.cocoon.ojb.samples.bean.Register, PK of the given object is [ > id=0], object was [EMAIL PROTECTED], > exception message is [Unknown Types value] > > Regards, > > Phil > > > - > 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: Object references... Fetched in a separate thread?
Hi Sean: AFAIK, this would not happen. BTW, what version are you using? Best Regards, Antonio Gallardo Sean Dockery dijo: > Hello there. > > I've had a curious experience recently with OJB, and I was wondering if > someone could confirm my speculations about the behaviour. > > Suppose I have two objects... Product and ProductCategory. The Product > object carries both a productCategoryId field as well as a reference field > productCategory which is declared as auto-retrieve in my class descriptor. > > Consider the following code segment... > > Transaction tx = implementation.newTransaction(); > tx.begin(); > PersistenceBroker broker = ((HasBroker) tx).getBroker(); > Product template = new Product(); > template.setId(productId); > Identity identity = new Identity(template, broker); > Product result = (Product) broker.getObjectByIdentity(identity); > tx.commit(); > > // Thread.sleep(50); > > System.out.println(result.getProductCategory().getName()); > > Curiously, I sometimes experience a null pointer exception because > result.getProductCategory() return null. When I uncomment the > Threat.sleep() call, the null pointer exception never happens. > > This seems to suggest that the productCategory reference is being loaded > by > another thread. Is this the case or can someone explain why > Product.getProductCategory returns null for me sometimes when I first > retrieve the Product object? > > Thanks for your time... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PB] - CollectionByQuery vs. IteratorByQuery
Hi: I am back. After some problems trying to subscribe this new mail address in the list. I finally managed it. I have a question: Currently we change some IteratorByQuery to CollectionByQuery using PB. While using IteratorByQuery we got every result and add it to a Collection. Are there a potential problem is we are using this to load some small catalogs with tens of registers? Thanks in advance. Best Regards, Antoino Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
I got 2 to 4 copies of the same mail?
Hi: Since 2 or 4 days ago I am receving from 2 to 4 copies of the same mail of this maillist. Is just happen to me or anyone else is experimenting the same problem? Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PB API] concurrency problems
Armin Waibel dijo:
> Hi Sven,
>
> I can reproduce your problem. It's a really nasty concurrency
> materialization problem when using global/shared caches and an object
> was materialized first time:
> Solution is to set attribute 'refresh="true"' in all
> reference-descriptor. This force OJB to lookup each reference for an
> object whether or not it was found in cache.
This is not a huge performance penality? If this is the solution, then why
we need a cache at all?
Best Regards,
Antonio Gallardo.
>
> regards,
> Armin
>
> Sven Efftinge wrote:
>
>> I just changed ObjectCacheClass from DefaultImpl to EmptyImpl.
>> Without caching the test doesn't fail.
>> I think this happens because the threads don't have to share the objects
>> in this case.
>> Sven
>>
>> Sven Efftinge wrote:
>>
>>> Hi Armin,
>>> I wrote a test for this, now.
>>> Unfortunately I wrote it against my application, because I haven't
>>> installed the OJB test suite yet ;(
>>> The test starts n threads. Each thread creates a PersistentBroker,
>>> retrieves 4 instances of an entity and then checks some references for
>>> each entity.
>>> When I run the test for 1 thread the test passes.
>>> When I run it for e.g. 30 threads the test fails(most of the time)
>>> because some references were null.
>>> Mmh... the test fails to RC4, also.
>>> I'm not sure if this is really the same problem because I don't get
>>> any errors from OJB directly. Only the null references.
>>>
>>> Here is the test (I used GroboUtils from SF):
>>>
>>>public void testConcurrentRead() throws Throwable {
>>>int numthreads = 30;
>>>TestRunnable[] tests = new TestRunnable[numthreads];
>>>
>>>for (int i = 0; i < tests.length; i++) {
>>>tests[i] = new FetchPersistentObjects();
>>>}
>>>MultiThreadedTestRunner testRunner =
>>>new MultiThreadedTestRunner(tests);
>>>
>>>testRunner.runTestRunnables();
>>>
>>>}
>>>
>>>class FetchPersistentObjects extends TestRunnable {
>>> /* (non-Javadoc)
>>> * @see
>>> net.sourceforge.groboutils.junit.v1.TestRunnable#runTest()
>>> */
>>>public void runTest() throws Throwable {
>>>PersistenceBroker broker = null;
>>>KontoIF konto = null;
>>>try {
>>>broker =
>>> PersistenceBrokerFactory.createPersistenceBroker(pbKey);
>>>Criteria crit = new Criteria();
>>>crit.addEqualTo(KONTO.NAME, "test");
>>>QueryByCriteria query = new
>>> QueryByCriteria(Konto.class, crit);
>>>//we have 4 kontos with name="test" in the database
>>>List kontos = (List) broker.getCollectionByQuery(query);
>>>for (Iterator iter = kontos.iterator(); iter.hasNext();)
>>> {
>>>konto = (KontoIF) iter.next();
>>>assertEquals("test", konto.getName());
>>>assertNotNull("All kontos have a reference to an
>>> interessent", konto.getInteressent());
>>>assertNotNull("All interessents have a reference to
>>> an adresse", konto.getInteressent().getAdresse());
>>>assertNotNull("All adresses have a reference to an
>>> adresseart", konto.getInteressent().getAdresse().getAdresseart());
>>>assertNotNull("All adressearts have a varname",
>>> konto.getInteressent().getAdresse().getAdresseart().getVarname());
>>>}
>>>} finally {
>>>broker.close();
>>>}
>>>}
>>>
>>>}
>>>
>>> Armin Waibel wrote:
>>>
>>>> Hi Sven,
>>>>
>>>> I don't know if your problem rely on a concurrency problem. Between
>>>> rc4 and rc5 I changed handling of DB resources in RsIterator class.
>>>> Now OJB is very strict in closing used resources. All resources will
>>>> be released when
>>>> - PB instance was closed
>>>> - PB commit call is done
>>>> - PB abort call is done
>>>> This helps to avoid abandoned Statement/ResultSet instances
RE: Optimistic Locking Integer/int Bug
Coup, Robert Muir dijo: > >> As you suggested, this is the old int/Integer problem. In OJB >> the prefered way is to avoid primitives datatypes (as int, >> boolean) and use only Object datatypes (as Integer, Boolean). >> >> I think the problem can be solved at the docs. If not then >> how we can test a int to null in Java? ;) > > Yeah I guess the best fix is in the docs. > > Or if ojb_version==0 then > 'UPDATE MyClassTable SET ojb_version='1', ... WHERE id='723' AND > (ojb_version='0' OR ojb_version is NULL)' > > The issue about it not always failing puzzled me a little. I'll try and > get a test case to reproduce it... Good idea. Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Optimistic Locking Integer/int Bug
Hi Robert:
As you suggested, this is the old int/Integer problem. In OJB the prefered
way is to avoid primitives datatypes (as int, boolean) and use only Object
datatypes (as Integer, Boolean).
I think the problem can be solved at the docs. If not then how we can test
a int to null in Java? ;)
Best Regards,
Antonio Gallardo
Coup, Robert Muir dijo:
> Hi,
>
> I think I found a minor bug in the optimistic locking (OL)
> code/documentation
>
> If you initialise an int field to use OL (locking="true") then updates
> will fail if the field is null, either silently or with a
> LockNotGrantedException.
>
> public class MyClass {
> private Integer id;
> private int ojbVersion;
> }
>
>
> primarykey="true" autoincrement="true"/>
> jdbc-type="INTEGER" locking="true"/>
>
> If a new object is created and persisted, the ojb_version field is set
> to 1 If another app inserts a record and the ojb_version field is null,
> when it is persisted then this SQL gets executed.
> UPDATE MyClassTable SET ojb_version='1', ... WHERE id='723' AND
> ojb_version='0'
>
> Sometimes this throws an exception, othertimes it seems to silently
> fail.
>
> Obviously it's the old int/Integer thing :)
> But in
> http://db.apache.org/ojb/faq.html#How%20to%20set%20up%20Optimistic%20Loc
> king it has: private int versionMaintainedByOjb
>
> Should the docs be changed to 'private Integer versionMaintainedByOjb'?
> If so, will it have issues 'incrementing' a null value? Or should in the
> docs it state 'make this table field default to a non-null value (eg.
> 0)'? Or should the code be doing 'UPDATE MyClassTable SET
> ojb_version='1', ... WHERE id='723' AND (ojb_version='0' OR ojb_version
> is NULL)'?
>
> Thanks,
>
> Rob :)
>
> -
> 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: ERROR: Invalid UNICODE character sequence found (0xc000)
Thomas Dudziak dijo: > Could you check this with the Postgres folks > (http://www.postgresql.org/lists.html) ? Perhaps it is best to post a bug > report there and wait for one of the developers to answer the report. Thanks for the tip. I already contacted people on the jdbc list, they send me to the general list and I suspect they will send me to the bug list. What a burucratic is the postgreSQL community! I cant believe it. It is worse than a corporation when you jump from one extension to another trying to solve your problem. :-( Anyway I will try to fill all the requirements to got the right people and try to solve it. ;-) Best Regards, Antonio Gallardo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ERROR: Invalid UNICODE character sequence found (0xc000)
Good news: This is not a OJB bug, it is a Postgres bug!
Steps to reproduce:
1. create a database using UNICODE (UTF-8):
createdb -E UNICODE mydbname.
2. create a table with some varchar inside, we will query on this field.
CREATE TABLE auth_role
(
rol_id int4 not null default
nextval('auth_rol_rol_id_seq'),
rol_namevarchar(50) unique not null,
rol_enable boolean default true,
primary key(rol_id)
);
INSERT INTO auth_role(rol_name,rol_enable) VALUES ('admin',true);
INSERT INTO auth_role(rol_name,rol_enable) VALUES ('zorro',true);
3. run psql and write:
SELECT * FROM AUTH_ROLE WHERE ROL_NAME LIKE 'z%';
4. You got the error!
ERROR: Invalid UNICODE character sequence found (0xc000)
The problem is related to the string 'z%'.
If you replace the string with 'a%' or za% or any other sequence that does
not contain 'z%" then you don't get the bug.
After all you was right, this is not a OJB related bug! :-D
Since we can also reproduce it using psql. I hoped it was my fault, but
looks like a postgresql bug. :-(
Please confirm the bug.
Best Regards,
Antonio Gallardo
> in psql the "SELECT version();" returns:
>
> PostgreSQL 7.3.4-RH on i386-redhat-linux-gnu, compiled by GCC
> i386-redhat-linux-gcc (GCC) 3.3.2 20031022 (Red Hat Linux 3.3.2-1)
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ERROR: Invalid UNICODE character sequence found (0xc000)
Thomas Dudziak dijo: > Well I'm no expert when it comes to PostgresSQL, but there seems to be > some problem between PostgresSQL and Java when using unicode. See here: > > http://linux.kieser.net/java_pg_unicode.html Thanks for the link. > > Also, PostgresSQL must be compiled with --enable-multibyte. Of course it is. > > Have you tried to specify the charSet in the jdbc url like this : > > jdbc:postgresql://[host]/[dbname]?charSet=UNICODE Yes, I already added this in my repository.xml and don't help. Please note I can use áéíóú without problem my problem is with the normal "z" in lower or upper case. AFAIK, this is not a problem in the postgres. > BTW this problem does not seem to exist with older (6.5) jdbc drivers. Not sure. My postgreSQL database is 7.3.4 and was installed from a rpm. Note we are able to create the database without any problem. We can also insert fields with "z" and search any string without "z". This is why I guess the problem is in OJB and not in the driver. > You could also use P6Spy to see what the offending SQL was. Hmm. I don't know how to use it. :-( Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERROR: Invalid UNICODE character sequence found (0xc000)
Hi:
I am getting this error while quering a simple table in a PostgreSQL
database. Interesting enough the error does not happen when we access the
database using other JDBC application.
The database was coded using:
createdb -E UNICODE myDBname
If I sent in the following code the variable filtro with "z" or "Z" it
throws an exception.
The problem occurs at this line:
Iterator qIter = broker.getIteratorByQuery(query);
The Java code is:
public void getList(Auth_userList bean, String filtro) throws Exception {
PersistenceBroker broker = null;
try {
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
// Define criterio
Criteria criterio = new Criteria();
if (filtro.length() > 0)
criterio.addLike(FILTRO, filtro + "*");
criterio.addNotEqualTo(FILTRO, "admin");
criterio.addOrderBy(FILTRO, true);
Query query = new QueryByCriteria(Auth_user.class, criterio);
Iterator qIter = broker.getIteratorByQuery(query);
while (qIter.hasNext()) {
Auth_user temp = new Auth_user();
PropertyUtils.copyProperties((Object)temp, (Object)qIter.next());
bean.add(temp);
}
} catch (Exception e) {
throw e;
} finally {
if (broker != null && !broker.isClosed()) {
broker.close();
}
}
}
Here is the full exception:
Note: The same apply for the drivers:
pg73jdbc.jar
pg74jdbc.jar
pg74.1jdbc.jar
Please explain.
Best Regards,
Antonio Gallardo
at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(Unknown
Source)
at org.apache.ojb.broker.accesslayer.RsQueryObject.performQuery(Unknown
Source)
at org.apache.ojb.broker.accesslayer.RsIterator.(Unknown Source)
at
org.apache.ojb.broker.core.RsIteratorFactoryImpl.createRsIterator(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getRsIteratorFromQuery(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getIteratorFromQuery(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getIteratorByQuery(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getIteratorByQuery(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getIteratorByQuery(Unknown
Source)
at test.miclassAuth_userHandler.getList(Auth_userHandler.java:81)
..
Caused by: java.sql.SQLException: ERROR: Invalid UNICODE character
sequence found (0xc000)
at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:131)
at
org.postgresql.jdbc1.AbstractJdbc1Connection.ExecSQL(AbstractJdbc1Connection.java:505)
at
org.postgresql.jdbc1.AbstractJdbc1Statement.execute(AbstractJdbc1Statement.java:320)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:48)
at
org.postgresql.jdbc1.AbstractJdbc1Statement.executeQuery(AbstractJdbc1Statement.java:153)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: java.lang.ArithmeticException: / by zero
Hi Edson: You comments are welcome! Carlos already found the problem. He miss a Primary key in one of the tables. Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Solved] java.lang.ArithmeticException: / by zero
Hi Armin: I reviewed again the O/R mapping and seems like 1 table currenlty have not PK defined. I will wait to Carlos and after he fix this problem I will post the results. Thanks for the tip. Now I know a little bit more about OJB. I am happy of this. :-)) Any way as a RFE, I think we can "enhance" a better description of the error at all instead of just write: Re: java.lang.ArithmeticException: / by zero Because our first reaction was: "Where is a div operation? We are coding DB, we don't wrote any div operation at all!" ;-) Have a nice hollydays! Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java.lang.ArithmeticException: / by zero
Armin Waibel dijo: > Hi Antonio, > > > > > Yes. we have all tables with PK. The class-descriptors has PK too. > > ok, maybe it's a bug in OJB. I'm not sure, but if the given class in > BasePrefetcher is an interface (class-descriptor only with extent > classes without fields), getPkFields().length will always return 0. Nope. This is not our case. We have just one class-descriptor for each table on the database. This is as Druid generate this. Here is an example: Right now I will write another mail, where I will show the segment model where I suspect the problem is. Many thanks for your time trying to help us. Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java.lang.ArithmeticException: / by zero
Hi Armin: Thanks for your answer! Armin Waibel dijo: > Hi Antonio, > > that's anyone's guess: > > > Caused by: java.lang.ArithmeticException: / by zero > >at > > > org.apache.ojb.broker.accesslayer.BasePrefetcher.(BasePrefetcher.java:116) > > In BasePrefetcher you can find the line > > pkLimit = getPrefetchInLimit() / > getItemClassDescriptor().getPkFields().length; > > So, do all your class-descriptors have a PK field-descriptor? Yes. we have all tables with PK. The class-descriptors has PK too. Best Regards, Antonio Gallardo > > regards, > Armin > > Antonio Gallardo wrote: > >> Hi Jakob: >> >> Thanks for the answer. I work with Carlos. I suggested Carlos to send a >> mail to the list, because I have no experience with this type of errors >> in >> OJB. >> >> He is on another project, but I tried to see into this problem too. We >> already compiled OJB with jar-debug option and here is the same error, >> but >> now with line numbers (see below). >> >> We have 2 days trying to solve it (before mail post) and we have no >> clues >> why this error happens. The O/R map (repository.xml) was generated using >> Druid (the same as my project that works fine). For me it looks like >> some >> relations inside the model are not well managed by OJB, but I am not >> sure >> of this. >> >> Here is more info: >> >> All the code worked good. Then when we insert a row in a particular >> table >> seems like the row "break" all the model. We checked inside the DB and >> the >> created row + relations are OK. We also checked the insert method and is >> good too. >> >> If we remove the offending row in the table everything works good. >> >> Please give us some advise or ask us more info you need to diagnostic >> this >> error. ;-D >> >> org.apache.ojb.broker.PersistenceBrokerException: >> java.lang.ArithmeticException: / by zero >> at >> org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:251) >> at >> org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:263) >> at >> org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollection(QueryReferenceBroker.java:514) >> at >> org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollections(QueryReferenceBroker.java:696) >> at >> org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(RsIterator.java:501) >> at >> org.apache.ojb.broker.accesslayer.RsIterator.next(RsIterator.java:293) >> at >> net.agssa.sga.forms.unidadmedida.UnidadmedidaHandler.getList(UnidadmedidaHandler.java:99) >> 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.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:230) >> at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244) >> at >> org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:1105) >> at >> org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:190) >> at >> org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:138) >> at >> org.mozilla.javascript.continuations.InterpretedFunctionImpl.call(InterpretedFunctionImpl.java:121) >> at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244) >> at >> org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:522) >> at >> org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:166) >> at >> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84) >> at >> org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:164) >> at >> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108) >> at >> org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:
Re: java.lang.ArithmeticException: / by zero
Hi Jakob: Thanks for the answer. I work with Carlos. I suggested Carlos to send a mail to the list, because I have no experience with this type of errors in OJB. He is on another project, but I tried to see into this problem too. We already compiled OJB with jar-debug option and here is the same error, but now with line numbers (see below). We have 2 days trying to solve it (before mail post) and we have no clues why this error happens. The O/R map (repository.xml) was generated using Druid (the same as my project that works fine). For me it looks like some relations inside the model are not well managed by OJB, but I am not sure of this. Here is more info: All the code worked good. Then when we insert a row in a particular table seems like the row "break" all the model. We checked inside the DB and the created row + relations are OK. We also checked the insert method and is good too. If we remove the offending row in the table everything works good. Please give us some advise or ask us more info you need to diagnostic this error. ;-D org.apache.ojb.broker.PersistenceBrokerException: java.lang.ArithmeticException: / by zero at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:251) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:263) at org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollection(QueryReferenceBroker.java:514) at org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollections(QueryReferenceBroker.java:696) at org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(RsIterator.java:501) at org.apache.ojb.broker.accesslayer.RsIterator.next(RsIterator.java:293) at net.agssa.sga.forms.unidadmedida.UnidadmedidaHandler.getList(UnidadmedidaHandler.java:99) 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.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:230) at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244) at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:1105) at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:190) at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:138) at org.mozilla.javascript.continuations.InterpretedFunctionImpl.call(InterpretedFunctionImpl.java:121) at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:522) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:166) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:164) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:163) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:152) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:354) at org.apache.cocoon.components.treeprocessor.TreeProcessor.handleCocoonRedirect(TreeProcessor.java:411) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:363) at org.apache.cocoon.components.treeprocessor.TreeProcessor.handleCocoonRedirect(TreeProcessor.java:411) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:363) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:307) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:133) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:164) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108) at org.apa
Re: jdo debug messages
Gus Heck dijo: > I googled around a bit, but I can't seem to find out how to turn off the > [JDO] debug messages that seem to be directed at standard out right now. > I am highly suspicious that this is controlled via log4j somehow, but I > don't know where the handle for that is in the OJB JDO implementation. > Can someone point me to where I can turn those messages on and off. They > are useful some of the time, but when I do a 100 iteration for loop in a > test case they get quite annoying. In OJB.properties change a line: JDO.LogLevel=DEBUG to: JDO.LogLevel=ERROR Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Order of field-descriptor id entries at repository
Thomas Dudziak dijo: > On Fri, 19 Dec 2003, Antonio Gallardo wrote: > >> Thomas Dudziak dijo: >> > Ah I see. Well, in the XDoclet module at least I could ensure that the >> > foreignkeys/inverse-foreignkeys are in the same order as the >> primarykeys. >> >> Hmm. I understand, we can have in a automatic tool a "sort" function >> that >> would allow us a predefined order. But as was pointed before we cannot >> rely on the position of the keys. It is not AFAIK OO or Relational at >> all. >> >> I think we need to fix it in OJB. > > I guess so. Since OJB can derive the correct ordering from the target > class descriptor, the same sorting could be added to OJB. Also, this > probably can be done at startup avoiding additional costs when accessing > the collection/reference. To be honest I don't saw it in the way you described above. But it looks like a great idea! It would solve the problem at all. :-D Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Order of field-descriptor id entries at repository
Thomas Dudziak dijo: > Ah I see. Well, in the XDoclet module at least I could ensure that the > foreignkeys/inverse-foreignkeys are in the same order as the primarykeys. Hmm. I understand, we can have in a automatic tool a "sort" function that would allow us a predefined order. But as was pointed before we cannot rely on the position of the keys. It is not AFAIK OO or Relational at all. I think we need to fix it in OJB. Best Regards, Antonio Gallardo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Order of field-descriptor id entries at repository
A similar thread is in the dev list: http://nagoya.apache.org/eyebrowse/ReadMsg?listId=106&msgNo=5522 Best Regards, Antonio Gallardo Thomas Dudziak dijo: >> I had some stange values aut objects since updated to RC5. >> After some debuging I found out that I got illegal values at attributes >> which does not match with the database. For example I got a attribute >> at tahe object with the value 15 where a 0 is stored at the >> corresponding >> database row. >> The solution was the sort order at the repository_user.xml. >> My repository_user.xml was auto generated and did not represent the >> correct >> order of field-descriptor id's. I former time this worked. >> Now it seems that the id's must have the correct order. After sorting >> the >> repository everything worked fine. All the fields had the correct id so >> it was not a real mapping error. I just thougt that OJB uses the >> field-descriptor for mapping the column. >> I'll now sort my repository an think that everything will work after >> that. >> Will this problem be fixed? I thing trusting in the position is >> dangerous. > > Could you perhaps post the repository_user.xml and the java source files ? > > Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ann] new release 1.0 RC5
Great! Congrats! :-) Best Regards, Antonio Gallardo Thomas Mahler dijo: > Dear all, > > After a long time of preparation we finally managed to assemble a new > release of OJB. > > We fixed a lot of bugs and we also improved the performance for all APIs. > > This is the last release candidate for 1.0. If no major bugs are > detected within the next two weeks this release will be relabled as 1.0. > We will provide a maintenance branch to provide those users with fixes > who wish to stay with a frozen 1.0 version. No new features will be > implemented in the maintenance branch. > > All new features and enhancements will be made in a new 1.1 branch. > > Thanks to everyone who helped to make this happen! > > from the release notes: > > ObJectRelationalBridge (OJB) is an Object/Relational mapping tool that > provides transparent transactional persistence for Java Objects against > relational databases. OJB provides ODMG and JDO interfaces. > > - > Release 1.0 rc5 > - > > This is the last planned rc before the 1.0 release. If there are no major > bugs this release will be relabled as 1.0 after two weeks. > > NEW FEATURES: > - With this release we are feature complete for the 1.0 release! > For 1.0 you should not expect more features to be added. > > NOTES: > - slight changes in repository.dtd, OJB.properties were made > > - internal kernel interface method signature changed: > in JdbcAccess two method signatures change > in StatementManagerIF one method signature change > These changes are necessary to fix a "design bug" in handling > of jdbc type metadata. See discussion on dev-list "[VOTE] Design bug > fixed - check in?" > > - ObjectCache implementation classes constructor arguments change. We > now pass a Properties argument too. Allows to set configuration properties > for each ObjectCache instance > > - changed the JDORI plugin to now use the latest 1.0.1 version of the > JDO reference implementation. > > - OJB is now very strict in handling RsIterator instances. RsIterator is > bound very closely to the used PersistenceBroker instance. > Thus if you do a > PersistenceBroker#close > PersistenceBroker#commitTransaction > PersistenceBroker#abortTransaction > call, the current RsIterator instance resources will be cleaned > up automatic > and invalidate current instance. > > CHANGES: > - add possibility to declare ObjectCache implementation on > class-descriptor > and jdbc-connection-descriptor level (means per class and per database > connection) too > > - add a new interface called org.apache.ojb.odmg.TransactionExt > to make additional proprietary methods available for user by > casting org.odmg.Transaction to TransactionExt > > - behaviour of org.odmg.Transaction#checkpoint() changed. Now the > database transaction was commited when checkpoint was called, seems this > is more in unison with ODMG spec: > " Calling checkpoint commits persistent object modifications made within > the > transaction since the last checkpoint to the database." > If you want to flush persistent object > modifications made within the ODMG transaction to the underlying database > transaction without commit the changes (old behaviour of checkpoint()), > please cast Transaction to TransactionExt and use new method flush(). > > - make odmg collections pluggable via OJB.properties file > > - Restructuring and further enhancements of the documentation. > > > BUG FIXES: > > Please refer to our Bug tracking site under > http://scarab.werken.com/scarab/issues/id/OJBxxx to see details for a bug > with id OJBxxx. > > - fix ClassLoader problem when merging DescriptorRepository instances > > - fixed the JDORI problems with loading object via extend based queries. >now objects are brought under JDO control and equipped with a > statemanager >in the load process. > > > enJoy the new release, > Thomas > > > > - > 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: WARN: Found unclosed resources while finalize
Hi Armin: Thanks for the answer. Reading again the first message it is OK. Of course your idea to set the log level to INFO is good. I think we can set it as default, because we are not creating any leak at all in this case. But the second message: [org.apache.ojb.broker.accesslayer.ResultSetAndStatement] ERROR: ** Associated resources (Statement/ResultSet) not closed! This could lead in leaking resources ** Is cause a big alarm to me. This means the app is leaking memory or I don't need to care about this second message? I just want to make sure you read this second message too. Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WARN: Found unclosed resources while finalize
Hi: I am getting this type of errors. I review the code and saw that we close the broker on every transaction. Can someone tell me why I am getting this errors? [org.apache.ojb.broker.accesslayer.RsIterator] WARN: Found unclosed resources while finalize (causer class: org.apache.ojb.broker.accesslayer.RsIterator) [org.apache.ojb.broker.accesslayer.ResultSetAndStatement] ERROR: ** Associated resources (Statement/ResultSet) not closed! This could lead in leaking resources ** Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using QueryBySQL to retrieve sequence value
Jakob Braeuchi dijo: > hi antonio, > > the queries provided by ojb require a class to be defined in the > repository. you can use any class defined in the repository in the > SQL-Query: > > QueryBySQL q = QueryFactory.newQuery(AnyClass.class,"select > mySequence.nextval from dual"); > Iterator iter = broker.getReportQueryIteratorByQuery(q); Problem I see is I have not any class, it is an independent sequence in the database. Can I create a dummy class just to take it? Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using QueryBySQL to retrieve sequence value
Jakob Braeuchi dijo:
> hi antonio,
>
> your QueryBySql will look for a class Integer in the repository ! and it
> will fail. use a ReportQuery to obtain rows from the database.
>
> hth
> jakob
Hi Jakob:
Thanks for the answer. The problem here is I am just quering a "nextval()"
from a sequence.
I will try the ReportQuery as you sugested, but I will be very glad if you
confim me how is the best way to get the required value.
Best Regards,
Antonio Gallardo
> Antonio Gallardo wrote:
>
>> Hi:
>>
>> I need to take a value from a sequence in PostgreSQL. The first idea is
>> to
>> run something like:
>>
>> QueryBySQL q = new QueryBySQL(Integer.class, "SELECT
>> nextval('mySequence');");
>> Integer seq = (Integer)broker.getObjectByQuery(q);
>>
>> Is this correct?
>> Exists another approach to do this?
>>
>> Best Regards,
>>
>> Antonio Gallardo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Persistence Broker 'NOT' Criteria
Jakob Braeuchi dijo:
> hi antonio,
>
> the parameter could be used to mark the whole criteria 'negative'. there
> would be no special addNot-method:
>
> Criteria crit1 = new Criteria();
> crit1.addEqualTo("field1","test1");
> crit1.addEqualTo("field2","test1");
> crit1.setNegative(true);
The point is: I can use after the above code:
crit1.setNegative(false);
Then:
where (field1=test1 and field2=test2)
Is this correct?
Best Regards,
Antonio Gallardo
>
> Criteria crit2 = new Criteria();
> crit2.addEqualTo("field3","test3");
> crit2.addEqualTo("field4","test4");
>
> crit1.addOr(crit2);
>
> result :
>
> select ... where NOT(field1=test1 and field2=test2) OR (field3=test3 AND
> field4=test4)
>
> jakob
>
> Antonio Gallardo wrote:
>> Jakob Braeuchi dijo:
>>
>>>hi robert,
>>>
>>>what do you think about a 'NOT'-flag in the criteria ?
>>>
>>>Criteri crit = new Criteria();
>>>
>>>crit.addEqualTo("field1","test1");
>>>crit.addEqualTo("field2","test1");
>>>crit.setNegative(true);
>>
>>
>> [RT]
>>
>> Is important to have the parameter in setNegative()? I guess, this is
>> because we can turn it off later. Right?
>>
>> I think when we build a criteria we already know if it would negative or
>> not. In that case the parameter is not needed at all.
>>
>> But maybe, in some special situation, someone can need to reverse the
>> setNegative() effect in the criteria. In this case the param is needed.
>>
>> This are just random thoughts about this topic.
>>
>> Best Regards,
>>
>> Antonio Gallardo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Using QueryBySQL to retrieve sequence value
Hi:
I need to take a value from a sequence in PostgreSQL. The first idea is to
run something like:
QueryBySQL q = new QueryBySQL(Integer.class, "SELECT
nextval('mySequence');");
Integer seq = (Integer)broker.getObjectByQuery(q);
Is this correct?
Exists another approach to do this?
Best Regards,
Antonio Gallardo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Howto provide my own Storage Classes
Claus Radloff dijo: > Hi, > > thank you for all your feedback. The approach with a custom persistance > broker sounds good to me. I will try this. > > My database (Oracle 9i) does handle the foreign key relations well, but > it needs significantly more time. The lookup of a single text is not the > problem. But when we select hundreds or thousands of records with one or > more references to texts, the performance penalty sums up quickly. Are you tried to "play" with some indexing? Often this is the sources of problems. Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Persistence Broker 'NOT' Criteria
Jakob Braeuchi dijo:
> hi robert,
>
> what do you think about a 'NOT'-flag in the criteria ?
>
> Criteri crit = new Criteria();
>
> crit.addEqualTo("field1","test1");
> crit.addEqualTo("field2","test1");
> crit.setNegative(true);
[RT]
Is important to have the parameter in setNegative()? I guess, this is
because we can turn it off later. Right?
I think when we build a criteria we already know if it would negative or
not. In that case the parameter is not needed at all.
But maybe, in some special situation, someone can need to reverse the
setNegative() effect in the criteria. In this case the param is needed.
This are just random thoughts about this topic.
Best Regards,
Antonio Gallardo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDO?
Michael Wolf dijo: >> download latest OJB CVS version. > > Do I have to use CVS for that or can I somehow download the latest > version from the ojb website? You need the CVS version with JDO 1.01. We are preparing the RC5 soon. RC5 will be released in the next 7 days. So if you prefer stay tunned and wait, but if you cannot wait, then I recommend you download the CVS version. Of course from the CVS will be the RC5 distro builded. So you will get early in touch with the RC5. BTW, I am currenlty using the CVS version. :-D Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Howto provide my own Storage Classes
Claus Radloff dijo:
> Hi,
>
> for some cases this could be a solution. But the majority needs the
> texts in all available languages, so the user can edit the description
> in these languages at once.
OK. I understand. For similars cases we builded a BeanList. And just
search by the first value, living the language free.
A two tables can be your solution:
class TextType
{
Integer id;
String type;
String name;
}
class Text
{
Integer id;
Integer language;
Map text;
}
In the O/R mapping, in TextType define a collection for Text. This would
work fine. We do the same for User and Permissions, where 1 user can have
many permisions.
Is this OK? :-D
Best Regards,
Antonio Gallardo
> Am Mo, 2003-12-08 um 12.01 schrieb Antonio Gallardo:
>> Hi Claus:
>>
>> Maybe this is not your solution, but are you tried PB using
>> QueryByIdentity? If the table has a 2 fields as PK, then you can easily
>> do:
>>
>> public Text retrieve(Integer id, Integer language, PersistenceBroker pb)
>> {
>> Text criteria = new Text();
>> criteria.setId(id);
>> criteria.setLanguage(language);
>> Query query = new QueryByIdentity(criterio);
>> Text result = (Text) pb.getObjectByQuery(query);
>> return result;
>> }
>>
>> I think it would not have a penality at all, will go directly to the
>> language you need.
>> This would help?
>>
>> Best Regards,
>>
>> Antonio Gallardo
>>
>>
>> Claus Radloff dijo:
>> > Hi,
>> >
>> > this does not solve the problem for me, because it works on already
>> > loaded instances of a class. My problem is, that I can't load my class
>> > with OJB, because the table I use to store these objects is not fully
>> > normalized (for performance reasons). So instead of one bean, OJB will
>> > probably return several beans to me. Since this table is referenced by
>> > nearly every other table, it would be very important to me, to
>> integrate
>> > it with OJB.
>> >
>> > The table looks like this:
>> >
>> > table texts
>> > id | name | type | language | text
>> > +---+--+--+---
>> > 1 | Warning | WARN | 1| Warning in english
>> > 1 | Warning | WARN | 2| Warning in german
>> > 2 | Hello | TEXT | 1| Hello
>> > 2 | Hello | TEXT | 2| Hallo
>> >
>> > The class looks like this:
>> >
>> > class Text
>> > {
>> > Integer id;
>> > String name;
>> > String type;
>> > Map texts;
>> > }
>> >
>> > The Map uses the language id as the key.
>> >
>> > So, if I used instance callbacks, I would get two beans for each text
>> > element, right?
>> >
>> > Normalizing this table into two tables isn't possible either, as it
>> > would result in poor performance.
>> >
>> > The easiest thing for me would be to implement my own storage classes,
>> > but I can't find a way to specify that.
>> >
>> > Regards
>> >
>> > Claus
>> >
>> > Thomas Mahler wrote:
>> >> The most easy approach is to use instance callbacks.
>> >> See http://db.apache.org/ojb/tutorial3.html#instance%20callbacks.
>> >>
>> >> you can place the additional lookup logic into the afterLookup
>> callback
>> >> The storage logic can be placed in the afterInsert callback.
>> >>
>> >> Only "disadvantage" of this approach: you persistent class must
>> >> implement the OJB interface PersistenceBrokerAware.
>> >>
>> >> cheers,
>> >> Thomas
>> >>
>> >> Claus Radloff wrote:
>> >> > Hello,
>> >> >
>> >> > I´d like to provide OJB with my own class to load/store objects in
>> the
>> >> > database. This is because I can´t get OJB to load this kind of
>> beans,
>> >> as
>> >> > they consist of multiple rows in the same table.
>> >> >
>> >> > To be able to load other classes with OJB, which reference these
>> >> > objects, I would like to tell OJB somehow to use my own
>> >> implementation.
>> >> > Is there a possibility to do so?
>> >> >
>> >> > What I imagine is something like:
>> >> > > >> > class="my.SpecialBean"
>> >> > storage-class="my.SpecialBeanStorage"/>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Howto provide my own Storage Classes
Hi Claus:
Maybe this is not your solution, but are you tried PB using
QueryByIdentity? If the table has a 2 fields as PK, then you can easily
do:
public Text retrieve(Integer id, Integer language, PersistenceBroker pb)
{
Text criteria = new Text();
criteria.setId(id);
criteria.setLanguage(language);
Query query = new QueryByIdentity(criterio);
Text result = (Text) pb.getObjectByQuery(query);
return result;
}
I think it would not have a penality at all, will go directly to the
language you need.
This would help?
Best Regards,
Antonio Gallardo
Claus Radloff dijo:
> Hi,
>
> this does not solve the problem for me, because it works on already
> loaded instances of a class. My problem is, that I can't load my class
> with OJB, because the table I use to store these objects is not fully
> normalized (for performance reasons). So instead of one bean, OJB will
> probably return several beans to me. Since this table is referenced by
> nearly every other table, it would be very important to me, to integrate
> it with OJB.
>
> The table looks like this:
>
> table texts
> id | name | type | language | text
> +---+--+--+---
> 1 | Warning | WARN | 1| Warning in english
> 1 | Warning | WARN | 2| Warning in german
> 2 | Hello | TEXT | 1| Hello
> 2 | Hello | TEXT | 2| Hallo
>
> The class looks like this:
>
> class Text
> {
> Integer id;
> String name;
> String type;
> Map texts;
> }
>
> The Map uses the language id as the key.
>
> So, if I used instance callbacks, I would get two beans for each text
> element, right?
>
> Normalizing this table into two tables isn't possible either, as it
> would result in poor performance.
>
> The easiest thing for me would be to implement my own storage classes,
> but I can't find a way to specify that.
>
>
> Regards
>
> Claus
>
>
>
> Thomas Mahler wrote:
>> The most easy approach is to use instance callbacks.
>> See http://db.apache.org/ojb/tutorial3.html#instance%20callbacks.
>>
>> you can place the additional lookup logic into the afterLookup callback
>> The storage logic can be placed in the afterInsert callback.
>>
>> Only "disadvantage" of this approach: you persistent class must
>> implement the OJB interface PersistenceBrokerAware.
>>
>> cheers,
>> Thomas
>>
>> Claus Radloff wrote:
>> > Hello,
>> >
>> > I´d like to provide OJB with my own class to load/store objects in the
>> > database. This is because I can´t get OJB to load this kind of beans,
>> as
>> > they consist of multiple rows in the same table.
>> >
>> > To be able to load other classes with OJB, which reference these
>> > objects, I would like to tell OJB somehow to use my own
>> implementation.
>> > Is there a possibility to do so?
>> >
>> > What I imagine is something like:
>> > > >class="my.SpecialBean"
>> >storage-class="my.SpecialBeanStorage"/>
>> >
>
>
> -
> 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: Problems using Tomcat + OJB
Rogerio Tambellini dijo: > Thanks for everyone, I just moved the files to WEB-INF/classes and worked. > > Unfortunatelly, in the OJB.properties, I had to write the fully static > directory to the repository file running at Tomcat. > > repositoryFile=../webapps/maritima/WEB-INF/classes/repository.xml I just have: repositoryFile=repository.xml Also you need to deploy on the same dir: OJB.properties and repository.dtd That way I managed to have it working on Tomcat. Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: [Druid-devel] Re: Druid, was: Re: Reposit]
Hi: Here is the answer. BTW, I don't like the work of being a bridge between OJB and Druid :-( Best Regards, Antonio Gallardo Mensaje Original Asunto: Re: [Druid-devel] Re: Druid, was: Re: Reposit De: "Andrea Carboni" Fecha: Mar, 18 de Noviembre de 2003, 20:42 Para: "Druid Devel" -- On 01:04, mercoledì 19 novembre 2003, Antonio Gallardo wrote: > Daniel R. Ambrosio dijo: > > Hello Guys, > > Hi Daniels, > > I am forwarding your request to Druid maillist. The internals of JDBC connection is out of my knowledges in Druid. It is also very new stuff in Druid. But I am sure Andrea or Bruno will be glad to answer your question. > > :-D > > Please don't take this mail in a bad sense. I am just trying to help you to solve the problem. > > To Druid Team: > > Druid is getting HOT in Apache OJB users. I think it is a very nice news to both teams. And I am very happy that this happens. :-D > Please check the message below > > Best Regards, > > Antonio Gallardo > > > I keep getting the message: ORA-01031: Insuficient Privileges?? > > > > What structure from the DB does Druid try to access while importing Entities?? Which privileges should I have. > > > > I use the same user I am trying now to connect to Druid in SQL Navigator, and there, I can see the tables´ structures without a problem. > > > > any help would be appreciated!! > > > > thanks, > > Daniel -- To forward to ojb mailing list -- The difference between the sql navigator and the table view is that the last one tries to retrieve all table information like indexes, foreign keys, privileges. If druid cannot import your schema then there is a table you are not allowed to access. Select with your mouse each node (table) you want to import. You should be able to see all table information until you get to the one you cannot access. If you receive this error for each table, then you need particular privileges to access oracle's data dictionary. Druid doesn't need CREATE,ALTER,DROP privileges but maybe it needs a SELECT ANY table to access the data dictionary (oracle's views). Cheers, Andrea --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Druid-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/druid-devel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Druid, was: Re: Reposit
Daniel R. Ambrosio dijo: > Hello Guys, Hi Daniels, I am forwarding your request to Druid maillist. The internals of JDBC connection is out of my knowledges in Druid. It is also very new stuff in Druid. But I am sure Andrea or Bruno will be glad to answer your question. :-D Please don't take this mail in a bad sense. I am just trying to help you to solve the problem. To Druid Team: Druid is getting HOT in Apache OJB users. I think it is a very nice news to both teams. And I am very happy that this happens. :-D Please check the message below Best Regards, Antonio Gallardo > I keep getting the message: ORA-01031: Insuficient Privileges?? > > What structure from the DB does Druid try to access while importing > Entities?? Which privileges should I have. > > I use the same user I am trying now to connect to Druid in SQL > Navigator, and there, I can see the tables´ structures without a problem. > > any help would be appreciated!! > > thanks, > Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Druid Working, More Info on How To
Robert S. Sfeir dijo: > Antonio the class suffix adds an _ before the name of it. So you end up > with a bean name with _Bean if your suffix is Bean. That's bad. I feel > there should be NO _ in the bean names. It is optional. Some people use this. Simply left it blank and it will does not add nothing to the name. Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Druid Working, More Info on How To
Jewett, Diane C dijo: > On the Apache OJB tab, What is package and class? "Package" means the package of the generated classes and "Class Suffix" is an optional suffix to be attached to every generated classes. Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Composite Foreign Keys
Eduardo Resende dijo: > Hi, I would like to know how can I map a composite foreign key in > repository_user.xml. Does the tag allow multiple > tags? yes. See: http://db.apache.org/ojb/repository.html Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
About Druid.
Hi: I am happy of the growing interest in using Druid to generate the repository.xml. :-D But I have concerns about the "Druid invasion" in the OJB list. And I hope OJB committers are not angry for this. Druid has also his own maillists: http://sourceforge.net/mail/?group_id=15111 But if all is OK. I can continue the this interesting dicussions here. I comment this for respect to OJB people that does not use Druid at all. Best Regards, Antonio Gallardo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Druid Working, More Info on How To
Charles Anthony dijo: > I suspect that Druid uses the foreign key metadata stuff in the driver to > do it's thang. If it ain't reported from MySql, Druid can't use it. Yep. You are right. If not how we can know what is FK and what not. It would be a very time consuming to do an analisis of the database. :-D Thanks for your comment about this MySQl bug. I don't use MySQL at all. Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Druid Working, More Info on How To
Robert S. Sfeir dijo: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > WOW! Foreign-Keys are as ass backwards as can be in Druid. Sorry if > the author is on here... but geez, relating foreign keys requires you to > click on a COLUMN TYPE and then scroll down to see it! makes no sense > if you ask me... but hey what ever works. Hi: I am jus a druid committer, I wrote the OJB and Java generator. We are aware there are still some type of situations when the generator does not works fine and the foreign key management inside druid is not the good one. We are trying to solve it in the next release. Also, please understand the OJB and Java generator are just 1 month olds. And I am totally newbie in OJB (2 or 3 months), so I studied the repository.xml, asked on the list some questions and build it. I thougt it will be improved with the time as we figured out how it would work better. It is part of my own interest to do that. But, right now I am totally busy with a project and we need to end by the end of the year. Anyway, I wrote this because I hate to write manually repository.xml and Beans by hand. I think it is a very boring work. :-D Thanks for your comments. Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Archives... http://db.apache.org/mail.html
Hi: It is true. The mailarchives in OJB are not the best for searching. Personally, I prefer MARC: http://marc.theaimsgroup.com/ If the OJB PMC agree I think it is a nice place to start an mailarchive for all maillist of OJB. BTW, Apache Cocoon use MARC between others and people prefer it. See: http://cocoon.apache.org/community/mail-archives.html Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Druid, was: Re: Reposit
Jakob Braeuchi dijo: > hi antonio, > > great, it works now :) Great to hear that! :-DDD Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Druid, was: Re: Reposit
Jakob Braeuchi dijo: > hi antonio, > > and how do i do it, please ! 1-On the left panel create a new empty database 2-Select the new create database, some tags appear on the right panel. 3-Click on the Jdbc panel. Fill your data there and after connect it 4-Click on Structure tab 5-select the "Jdbc database" and open it 6-Select "public" and right click on them 7-On the popup menu select import entities. That is all! Remember to define your datatypes and define some generators for you database. Druid id really easy and great! Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jbdc connection info of all DB.
Hi: Where I can found all the info about this elements in : com.caucho.jdbc.mysql.Driver jdbc mysql-caucho //localhost:3306/storefront'/ I think it would be fine to include this is Druid. Currently, druid only autogenerate this info for PostgreSQL Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Druid, was: Re: Reposit
Jakob Braeuchi dijo: > hi antonio, > > how can i import existing tables ? Yep. Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with java.util.Date in Form and java.sql.Date in OJB
Druid is updated in CVS, please update it if you need this stuff. I added a need switch in OJB generation: use Date Convertor. Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with java.util.Date in Form and java.sql.Date in OJB
Armin Waibel dijo: > Hi, > > use a FieldConversion > e.g. JavaDate2SqlDateFieldConversion > > see http://db.apache.org/ojb/jdbc-types.html Thanks Armin. In fact the solution is great: Just add to the field a new attribute: conversion="org.apache.ojb.broker.accesslayer.conversions.JavaDate2SqlDateFieldConversion" Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with java.util.Date in Form and java.sql.Date in OJB
Hi: I know we need to use java.sql.Date in OJB. I have some Objects that returns me java.util.Date. Can OJB manage this? is there an easy conversion to solve this problem? My problem is because Cocoon Forms need to manage java.util.Date and OJB java.sql.Date. If you know how I can solve this with a current conversion inside OJB. Please let me know :-D I am using JDO inside OJB. Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB Still alive?
Brian McCallister dijo: > additional tool support is appearing weekly it seems (go Druid, now that > I got it working (thank you Antonio!)). :-D Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: unknown isolation-level Warning
A Leg dijo: > Hi > > At start of my application I get this warning, anything else are good > working. But I would prefer understand and correct it. > > [org.apache.ojb.broker.metadata.RepositoryXmlHandler] WARN: unknown > isolation-level: read-uncomminted using RW_UNCOMMITTED as default I see you don't downloaded from the CVS druid. This is a bug in druid released version. Workaround: Change "read-uncomminted" to "read-uncommitted" in your generated jdbc-connection or to get rid of all other problems: Download Druid from the CVS. It is full functional. Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Druid, was: Re: Reposit
Brian McCallister dijo: > Druid is really cool, but I have never actually gotten the code > generation to work. When I hook it to an existing DB, import the > entities and go to code generation and I get an error saying datatypes > are set on all of my foreign keys =/ Hi Brian: You need to define "DD equiv." field for your datatypes at the database level: Select the database. Select the "Data Types" tab. For every datatype define the datatype you want to use in Java. Example: Druid Type --> DD equiv. bit--> Boolean Varchar--> String, etc. Then try again. BTW, try better the CVS version, because the official release had some bug in OJB generation. Best Regards, Antonio Gallardo. > > -Brian > > On Wednesday, November 12, 2003, at 05:19 PM, Antonio Gallardo wrote: > >> Gus Heck dijo: >>> This is probably a terribly noob question, but is there a good way to >>> generate my object mappings for the repository.xml? Seems like a lot >>> of >>> tedium to do it for more than one or two classes. >> >> Hi Gus: >> >> Druid - http:// druid.sf.net/ - Please, download it from the CVS. >> >> Best Regards, >> >> Antonio Gallardo >> >> >> - >> 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: Reposit
Gus Heck dijo: > This is probably a terribly noob question, but is there a good way to > generate my object mappings for the repository.xml? Seems like a lot of > tedium to do it for more than one or two classes. Hi Gus: Druid - http:// druid.sf.net/ - Please, download it from the CVS. Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: with-jdori broken?
Armin Waibel dijo: > PB-api and ODMG-api implementations are stable and used in > production. > The "real work" of the JDO implementation (backed by the OTM-api) > will be start after the 1.0/1.1 release. hmm...?!. I am already using OJB with JDO. Sometimes we need to "loan" some API from PB. But all the rest works fine. ;-D Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sequence number for the last insert
Morgan Soe dijo: > Hello, I am trying to find out if there is a simple way to get the > sequence number for the last insert from a table with auto-incremented > primary key column. Check this: http://db.apache.org/ojb/howto-use-db-sequences.html Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: with-jdori broken?
Hi Gus: First, you dont need to said: > I am getting the feeling that the JDO > implementation here is sketchy and really very beta or alpha, not so RC > ish... But I am probably doing something very wrong. Please remember: You will find help on the list without making this type of comments. Now to the things: Are you using JDO 1.00 or JDO 1.01? You need JDO 1.00. OJB does NOT work with JDO 1.01. Best Regards, Antonio Gallardo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any body can help me?
Can you send the full stack trace? Maybe you miss a "caused by" or a "nested exception". Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question about getIteratorByQuery
A Leg dijo: > You mean that the ojb iterator work exactly in the same the database > iterator works, taking in count the caching issues ? yep. Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem with tutorial part 4 example
Thomas Mahler dijo: > Please point me to the 1.0.1 release and I'll check if there are any > compilation problems. Yep Thomas there is a problem with the 1.01 release. It does not work with OJB. Would be fine if you check this closer. 1.01 fix many bugs from 1.0 And I am sure many people will welcome the changes. The link to 1.01 is: http://access1.sun.com/jdo/ Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: o.a.ojb.broker.PersistenceBrokerSQLException: Unknown Types value
Hi Thomas: Thomas Mahler dijo: > Antonio Gallardo wrote: >> I wondering why OJB does not support BOOLEAN, since it is a valid type >> for JDBC 3.0. > > No special reason. Only laziness ;-) It is an enough and good supported reason! :- Anyway, BIT works fine. I updated druid too. Best Regards, Antonio Gallardo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDO over OJB - both metadata files?
Nick Ohanian dijo: > Hi- > > I have a question about using the JDO API with OJB. OJB requires the > O/R mapping be stored in the repository.xml file. But when using JDO, > class enhancement requires a package.jdo (or some other .jdo file) to > specify the same mapping. These files store almost the exact same > information, just in slightly different formats. > So do both files have to be continuously separately maintained? Currently this is true. BUt the JDO can be more simply. You don't need to define there collections or references. Best Regards, Antonio Gallardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: o.a.ojb.broker.PersistenceBrokerSQLException: Unknown Types value
Hi: Thanks! It works. I wondering why OJB does not support BOOLEAN, since it is a valid type for JDBC 3.0. Best Regards, Antonio Gallardo Gelhar, Wallace Joseph dijo: > Hi Antonio, > > Try using BIT as the type. > > Wally Gelhar > > -Original Message- > From: Antonio Gallardo > Sent: Saturday, November 08, 2003 6:01 AM > To: [EMAIL PROTECTED] > Subject: o.a.ojb.broker.PersistenceBrokerSQLException: Unknown Types > value > > Hi: > > I am trying to insert the following class into a PostgreSQL DB using > JDO. > I got an Exception: > > org.apache.ojb.broker.PersistenceBrokerSQLException: Unknown Types > value. > > I noted OJB correctly got the nextVal of the sequence. But then it throw > the exception. > > Questions: > > Is supported the BOOLEAN datatype? > > Or if there is other problem, please help. > > Best Regards, > > Antonio Gallardo > > > >autoincrement="true" sequence-name="auth_rol_rol_id_seq" column="ROL_ID" > jdbc-type="INTEGER"/> >jdbc-type="VARCHAR"/> >jdbc-type="BOOLEAN"/> >element-class-ref="test.Auth_user_role" auto-update="false" > auto-delete="false"> > > >element-class-ref="test.Auth_permission" auto-update="false" > auto-delete="false"> > > > > > [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] ERROR: SQLException > during the execution of the insert (for a test.Auth_role): Unknown Types > value. > Unknown Types value. > Unknown Types value. > at > org.postgresql.jdbc1.AbstractJdbc1Statement.setObject(AbstractJdbc1State > ment.java:1423) > at > org.postgresql.jdbc1.AbstractJdbc1Statement.setObject(AbstractJdbc1State > ment.java:1429) > at > org.apache.ojb.broker.platforms.PlatformDefaultImpl.setObjectForStatemen > t(Unknown > Source) > at > org.apache.ojb.broker.platforms.PlatformPostgreSQLImpl.setObjectForState > ment(Unknown > Source) > at > org.apache.ojb.broker.accesslayer.StatementManager.bindInsert(Unknown > Source) > at > org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeInsert(Unknown > Source) > at > org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(Unknown > Source) > at > org.apache.ojb.broker.core.PersistenceBrokerImpl.store(Unknown Source) > at > org.apache.ojb.broker.core.PersistenceBrokerImpl.store(Unknown Source) > at > org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(Unknown > Source) > at > org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(Unknown > Source) > at org.apache.ojb.jdori.sql.OjbStoreManager.insert(Unknown > Source) > at com.sun.jdori.common.state.PersistentNew.flush(Unknown > Source) > at com.sun.jdori.common.state.StateManagerImpl.flush(Unknown > Source) > at org.apache.ojb.jdori.sql.OjbStoreManager.flush(Unknown > Source) > at com.sun.jdori.common.CacheManagerImpl.flushInstances(Unknown > Source) > at > com.sun.jdori.common.PersistenceManagerImpl.flushInstances(Unknown > Source) > at com.sun.jdori.common.TransactionImpl.flushInstances(Unknown > Source) > at com.sun.jdori.common.TransactionImpl.prepareFlush(Unknown > Source) > at com.sun.jdori.common.TransactionImpl.commit(Unknown Source) > at > ni.gob.mific.ait.forms.Auth_roleHandler.insert(Auth_roleHandler.java:35) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav > a:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor > Impl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at > org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:230) > at > org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244) > at > org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(C > ontinuationInterpreter.java:1105) > at > org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(C > ontinuationInterpreter.java:190) > at > org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(C > ontinuationInterpreter.java:138) > at > org.mozilla.javascript.continuations.InterpretedFunctionImpl.call(Interp > retedFunctionImpl.java:121) > at > org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244) > at > org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java
o.a.ojb.broker.PersistenceBrokerSQLException: Unknown Types value
Hi: I am trying to insert the following class into a PostgreSQL DB using JDO. I got an Exception: org.apache.ojb.broker.PersistenceBrokerSQLException: Unknown Types value. I noted OJB correctly got the nextVal of the sequence. But then it throw the exception. Questions: Is supported the BOOLEAN datatype? Or if there is other problem, please help. Best Regards, Antonio Gallardo [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] ERROR: SQLException during the execution of the insert (for a test.Auth_role): Unknown Types value. Unknown Types value. Unknown Types value. at org.postgresql.jdbc1.AbstractJdbc1Statement.setObject(AbstractJdbc1Statement.java:1423) at org.postgresql.jdbc1.AbstractJdbc1Statement.setObject(AbstractJdbc1Statement.java:1429) at org.apache.ojb.broker.platforms.PlatformDefaultImpl.setObjectForStatement(Unknown Source) at org.apache.ojb.broker.platforms.PlatformPostgreSQLImpl.setObjectForStatement(Unknown Source) at org.apache.ojb.broker.accesslayer.StatementManager.bindInsert(Unknown Source) at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeInsert(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.store(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.store(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(Unknown Source) at org.apache.ojb.jdori.sql.OjbStoreManager.insert(Unknown Source) at com.sun.jdori.common.state.PersistentNew.flush(Unknown Source) at com.sun.jdori.common.state.StateManagerImpl.flush(Unknown Source) at org.apache.ojb.jdori.sql.OjbStoreManager.flush(Unknown Source) at com.sun.jdori.common.CacheManagerImpl.flushInstances(Unknown Source) at com.sun.jdori.common.PersistenceManagerImpl.flushInstances(Unknown Source) at com.sun.jdori.common.TransactionImpl.flushInstances(Unknown Source) at com.sun.jdori.common.TransactionImpl.prepareFlush(Unknown Source) at com.sun.jdori.common.TransactionImpl.commit(Unknown Source) at ni.gob.mific.ait.forms.Auth_roleHandler.insert(Auth_roleHandler.java:35) 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.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:230) at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244) at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:1105) at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:190) at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:138) at org.mozilla.javascript.continuations.InterpretedFunctionImpl.call(InterpretedFunctionImpl.java:121) at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244) at org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1591) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.handleContinuation(FOM_JavaScriptInterpreter.java:606) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:165) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:164) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:163) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:152) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:354) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:307) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:132) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84) at
RE: Loading an object
Hi:
It would be fine to test also concurrent clients reading from the database
and see the results for both.
Best Regards,
Antonio Gallardo
Florin Pop dijo:
> Hi Thomas,
>
> indeed if I repetead the lookup(using different ids) 100 times or even
> 1000 times the difference is decreasing, proportionally speaking.
>
> iterationsHibernate OJB
> 1 .122s .867s
> 100 1.50s 3.09s
> 1000 12.90s 25.54s
>
>
> I agree with you this is a basic performance test, but I was surprised
> seeing that for a simple load the difference is that big.
>
>
> Regards,
>
> florin
>
> -Original Message-
> From: Mahler Thomas [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 04, 2003 4:21 PM
> To: 'OJB Users List'
> Subject: RE: Loading an object
>
>
> Hi Florin,
>
> IMO it makes not much sense to compare the performance of two
> persistence engines based on such a simplified test.
> You must test things like working with real world object models,
> with high loads over a longer period of time,
> multi user access scenarios, etc.
>
> I don't know about Hibernate, but OJB at least has a "warming up" phase.
> So for this simple test hings will look differenet if you perform it in
> a loop with say 10 000 iterations!
>
> cu,
> Thomas
>
>> -Original Message-
>> From: Florin Pop [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, November 04, 2003 3:09 PM
>> To: '[EMAIL PROTECTED]'
>> Subject: RE: Loading an object
>>
>>
>> Hi bellow are the 2 methods
>>
>> public void testLoadPersonUsingOJB() throws Exception {
>> long time = System.currentTimeMillis();
>> final long PERSON_ID = 112327;
>> Person person = new Person();
>> Identity id = new Identity(Person.class,
>> Person.class, new Long[]
>> {new Long(PERSON_ID)});
>> person = (Person) broker.getObjectByIdentity(id);
>> assertTrue(person != null);
>> assertTrue(null != person.getBirthday());
>> assertTrue(null != person.getCitizenship());
>> assertTrue(null != person.getCity());
>> assertTrue(null != person.getFirstName());
>> assertTrue(null != person.getName());
>> assertTrue(null != person.getStreet());
>> time = System.currentTimeMillis() - time;
>> System.out.println(time);
>> }
>>
>> public void testLoadPersonUsingHibernate() throws Exception {
>> long time = System.currentTimeMillis();
>> final long PERSON_ID = 112327;
>> Person person = (Person) session.load(Person.class, new
>> Long(PERSON_ID));
>> assertTrue(person != null);
>> assertTrue(null != person.getBirthday());
>> assertTrue(null != person.getCitizenship());
>> assertTrue(null != person.getCity());
>> assertTrue(null != person.getFirstName());
>> assertTrue(null != person.getName());
>> assertTrue(null != person.getStreet());
>> assertTrue(null != person.getFullName());
>> time = System.currentTimeMillis() - time;
>> System.out.println(time);
>> }
>>
>> the session(4 hibernate) and the broker (4 OJB) are initialized in the
>> constructors.
>>
>>
>> Regards,
>>
>> florin
>>
>> -Original Message-
>> From: Armin Waibel [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, November 04, 2003 3:40 PM
>> To: OJB Users List
>> Subject: Re: Loading an object
>>
>>
>> Hi,
>>
>> Florin Pop wrote:
>>
>> > Hi again,
>> >
>> > I have tried your suggested approach but curiously the same result.
>> >
>> > The tests that I run consist just in loading an Person
>> object from the
>> data
>> > source. Both with Hibernate and with OJB I use no cache and
>> this load
>> > operation is the first and only one opperation that I execute in one
>> session. So there is no object cached anywhere.
>> >
>> > For me is also very surprizing the result.
>> >
>> For me too!
>>
>> How does your test looks like?
>>
>> long time = System.currentTimeMillis();
>> Person person = (Person) broker.getObjectByQuery(query);
>> time = System.currentTimeMillis() - time;
>>
>> Can you post source of both test?
>>
>> regards,
>> Armin
>>
>>
>> > Regards,
>> > Florin
>> >
>>
