cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <mccallis...@forthillcompany.com>
Subject Re: Problem with OJB
Date Wed, 07 Apr 2004 16:41:30 GMT
Which version of OJB are you using? Line numbers don't match up to the  
one I have, which is, admittedly, cvs head -- though rc6 and cvs head  
are pretty similar right now.

Okay, some try-the-common-things-first:

Try changing the PK and FK values to Integer types instead of int.  
Using the primitives can really boggle OJB as it is not safe to presume  
0 is equivalent to not-set (null).

Test.

Remove the "default-fetch" as it only applies to JDO rinse, repeat.

Will look at more carefully asap =)

-Brian

On Apr 7, 2004, at 9:56 AM, Mike Ahlers wrote:

> Hi Brian,
>
> I can try...  let me describe what I got so far. After digging deeper  
> into this and producing some relevant debug statements I find the  
> following written on my console:
>
> console output:
> --- start snippet ---
> NVTPDataAccessObject2: getArticle: called with id: 56
> [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: executeQuery  
> : Query from class nl.hippo.nvpt.Articles where [id = 56]
> [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:  
> SQL:SELECT  
> A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L 
> OGIN,A0
> .WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.MATRICE_ID,A0.EMAIL,A0.CONTACT 
> PERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0.ID FROM ARTICLES A0 WHERE  
> A0.ID = ?
> [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG:  
> executeQuery: com.mysql.jdbc.PreparedStatement@13c33b7: SELECT  
> A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L 
> OGIN,A0.WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.
> MATRICE_ID,A0.EMAIL,A0.CONTACTPERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0. 
> ID FROM ARTICLES A0 WHERE A0.ID = 56
> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG:  
> RsIterator[org.apache.ojb.broker.accesslayer.RsQueryObject[query:  
> Query from class nl.hippo.nvpt.Articles where [id = 56], class  
> descriptor: nl.hippo.nvpt.Articles]] initialized
> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
> [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:  
> SQL:SELECT NAAM,OMSCHRIJVING,ID FROM ARTICLE_TYPES WHERE ID = ?
> [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: executeQuery  
> : Query from class nl.hippo.nvpt.Articles where [type = 3]
>                                                                         
>                                                                         
>                          ^^^^^^
>
> [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG:  
> SQL:SELECT  
> A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L 
> OGIN,A0
> .WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.MATRICE_ID,A0.EMAIL,A0.CONTACT 
> PERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0.ID FROM ARTICLES A0 WHERE  
> A0.TYPE = ?
> [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG:  
> executeQuery: com.mysql.jdbc.PreparedStatement@1f8f8c8: SELECT  
> A0.TELEFOON,A0.TREFWOORDEN,A0.TYPE,A0.PARTNER,A0.PASSWORD,A0.KLANT,A0.L 
> OGIN,A0.WERKZAAMBIJ,A0.TITEL,A0.OMSCHRIJVING,A0.
> MATRICE_ID,A0.EMAIL,A0.CONTACTPERSOON,A0.BESTAND,A0.CORP_ID,A0.BRON,A0. 
> ID FROM ARTICLES A0 WHERE A0.TYPE = 3
> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG:  
> RsIterator[org.apache.ojb.
> broker.accesslayer.RsQueryObject[query: Query from class  
> nl.hippo.nvpt.Articles where [type = 3], class descriptor:  
> nl.hippo.nvpt.Articles]] initialized
> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
> ...
> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() -> true
> [org.apache.ojb.broker.accesslayer.RsIterator] DEBUG: hasNext() ->  
> false
> java.lang.ArithmeticException: / by zero
>        at  
> org.apache.ojb.broker.accesslayer.BasePrefetcher.<init>(BasePrefetcher. 
> java:115)
>        at  
> org.apache.ojb.broker.accesslayer.RelationshipPrefetcherImpl.<init>(Rel 
> ationshipPrefetcherImpl.java:78)
>        at  
> org.apache.ojb.broker.accesslayer.CollectionPrefetcher.<init>(Collectio 
> nPrefetcher.java:97)
>        at  
> org.apache.ojb.broker.accesslayer.RelationshipPrefetcherFactory.createR 
> elationshipPrefetcher(RelationshipPrefetcherFactory.java:85)
>        at  
> org.apache.ojb.broker.core.QueryReferenceBroker.performRetrievalTasks(Q 
> ueryReferenceBroker.java:315)
>        at  
> org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Qu 
> eryReferenceBroker.java:185)
>        at  
> org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Qu 
> eryReferenceBroker.java:242)
>        at  
> org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Qu 
> eryReferenceBroker.java:262)
>        at  
> org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollection(Quer 
> yReferenceBroker.java:513)
>        at  
> org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollections(Que 
> ryReferenceBroker.java:695)
>        at  
> org.apache.ojb.broker.core.PersistenceBrokerImpl.getDBObject(Persistenc 
> eBrokerImpl.java:1153)
>        at  
> org.apache.ojb.broker.core.PersistenceBrokerImpl.doGetObjectByIdentity( 
> PersistenceBrokerImpl.java:1217)
>        at  
> org.apache.ojb.broker.core.QueryReferenceBroker.getReferencedObject(Que 
> ryReferenceBroker.java:478)
>        at  
> org.apache.ojb.broker.core.QueryReferenceBroker.retrieveReference(Query 
> ReferenceBroker.java:358)
>        at  
> org.apache.ojb.broker.core.QueryReferenceBroker.retrieveReferences(Quer 
> yReferenceBroker.java:400)
>        at  
> org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(RsI 
> terator.java:501)
>        at  
> org.apache.ojb.broker.accesslayer.RsIterator.next(RsIterator.java:293)
>        at  
> org.apache.ojb.broker.core.PersistenceBrokerImpl.getObjectByQuery(Persi 
> stenceBrokerImpl.java:1298)
>        at  
> org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByQuery 
> (DelegatingPersistenceBroker.java:291)
>        at  
> org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByQuery 
> (DelegatingPersistenceBroker.java:291)
>        at nl.hippo.nvpt.NVTPDataAccessObject2.getArticle(Unknown  
> Source)
> --- end snippet ---
>
> Note the sudden 'translation' of 'Article_types' into 'Articles'. I am  
> expecting a query like: Query from class nl.hippo.nvpt.Article_types  
> where [type = 3] and not Query from class nl.hippo.nvpt.Articles where  
> [type = 3]. Could this a bug in the SqlGeneratorDefaultImpl regarding  
> nested queries? Anyways, this is what I am trying to map:
>
> repository.xml:
> --- start snippet ---
> <class-descriptor class="nl.hippo.nvpt.Articles" table="ARTICLES">
>    <field-descriptor name="id" primarykey="true" default-fetch="true"  
> column="ID" jdbc-type="INTEGER"/>
>    <field-descriptor name="type" default-fetch="true" column="TYPE"  
> jdbc-type="INTEGER"/>
>    ....
>    <reference-descriptor name="article_types"  
> class-ref="nl.hippo.nvpt.Article_types" auto-update="false"  
> auto-delete="false">
>            <foreignkey field-ref="type"/>
>    </reference-descriptor>
> </class-descriptor>
> --- end snippet ---
>
> The following classes are generated (like the repository.xml) by Druid  
> and has setters and getters.
>
> Articles.java:
> --- start snippet ---
> public class Articles {
> public int        id;
> public int        type;
> public Article_types article_types;
> ...
> }
> --- end snippet ---
>
> Article_types:
> --- start snippet ---
> public class Article_types
> {
> public int        id;
> public String     naam;
> public String     omschrijving;
> }
> --- end snippet ---
>
> My data access object looks like this:
> --- start snippet ---
> public Articles getArticle(int id) {
> ...
> System.out.println("NVTPDataAccessObject2: getArticle: called with id:  
> " + id);
> broker = PersistenceBrokerFactory.defaultPersistenceBroker();
> // Create criteria
> criteria = new Criteria();
> criteria.addEqualTo("id", new Integer(id));            // Refine  
> criteria
> // Create query
> query = new QueryByCriteria(Articles.class, criteria);
> result = (Articles) broker.getObjectByQuery(query);
> ...
> return result;
> --- end snippet ---
>
> Brian McCallister wrote:
>
>> Any chance you can post the relevent repository_user.xml snippets and  
>> an outline at least of what they map to? More than happy to help you  
>> work out what's going on =)
>>
>> I have never seen divide by zero errors from OJB =(
>>
>> Also, do you get the same problem if you try the query via the  
>> PersistenceBroker api instead of the JDO api?
>>
>> -Brian
>>
>> On Apr 7, 2004, at 5:44 AM, Mike Ahlers wrote:
>>
>>> Hi,
>>>
>>> I am a new kid on the block and work with the OJB/JDO block. Using a  
>>> database with no relations works perfectly, however when I increase  
>>> complexity and use foreign keys I fail to get it working. The  
>>> following error is what I get:
>>>
>>> [org.apache.ojb.broker.accesslayer.RsIterator] ERROR: Error while  
>>> iterate Result Set for query  
>>> org.apache.ojb.broker.accesslayer.RsQueryObject[query: Query from  
>>> class nl.hippo.nvpt.Articles where [id = 55], class descriptor:  
>>> nl.hippo.nvpt.Ar
>>> ticles]
>>> / by zero java.lang.ArithmeticException: / by zero
>>>
>>> Can anybody explain why iterating over a result-set gives a div by  
>>> zero?
>>>
>>> Thanks in advance,
>>> Mike Ahlers
>>>
>>>
>>
>>
>>
>
>
>




Mime
View raw message