[JAVA/HIBERNATE] HQL problemen

Pagina: 1
Acties:

  • Nibble
  • Registratie: Juli 2001
  • Laatst online: 13-04 15:26
Mede tweakerds, ik zit met een probleem waar ik nu al ruim een dag op zit te bikkelen en ik kom er niet uit. Ik ben bezig met een applicatie icm hibernate. Eerst even een stukje jsp code:

Java:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
try{
        //Verkrijg een sessie en begin een transaction
       hibernateSession = AppSession.getSession();
       myTransaction = hibernateSession.beginTransaction();                     
                
        //Query hql = hibernateSession.createQuery("from Customer c where c.account.id in             (select a.id from Account a where a.id = "+request.getParameter("id")+ ") group by c.account.id");                    
        //Query hql = hibernateSession.createQuery("from Customer c where c.account.id =  "+request.getParameter("id"));

        Query hql = hibernateSession.createQuery("from Customer as c");         
        
        
        customers = hql.list();                                                     
                myTransaction.commit();
        
        
        } catch (Exception e) {
        error = e.getMessage(); e.printStackTrace();
            try{ myTransaction.rollback(); 
               } catch (Exception e2){;}
        }
    finally {
        try { hibernateSession.close();}
        catch (Exception e){;}
    }   


Oorspronkelijk was het de bedoeling dat ik een lijst met customers krijg van de klasse Customer die naast een aantal properties een object Account in zich heeft. Ik wil alleen de gegevens hebben van die Customers die geassocieerd zijn met het Account.id = x.
Momenteel ben ik al blij als ik uberhaupt een lijst met customers terug krijg vandaar de uitgecommentaarde eerdere queries. Uiteraard moet er later nog een iterator op komen maar zover kom ik niet eens momenteel.

Als ik deze HQL query uitvoer duurt het eonen voordat ik een result krijg van de server met als resultaar (uit de logs):

code:
1
2
2006-01-12 09:25:44 StandardWrapperValve[jsp]: Servlet.service() for servlet jsp threw exception
java.lang.OutOfMemoryError: Java heap space


De database bestaat, connectie maken lukt, hibernate configuratie is in orde en dingen zoals

Java:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
try{

        //Verkrijg een sessie en maak een iterator op de Customer tabel.
        hibernateSession = AppSession.getSession();
        myTransaction = hibernateSession.beginTransaction();                
        Criteria query = hibernateSession.createCriteria(Customer.class);               
        customers = query.list().iterator();                            
        myTransaction.commit();
        
        } catch (Exception e) {
        error = e.getMessage(); e.printStackTrace();
            try{ myTransaction.rollback(); 
               } catch (Exception e2){;}
        }
        finally {
            try { hibernateSession.close();}
            catch (Exception e){;}
        }       


lukken wel (maar dat is dus met criteria en niet met HQL) en ik heb HQL nodig omdat ik onder water straks versiebeheer moet plegen op records...lang verhaal)

De tabel Customer bevat momenteel 1 record en de tabel Account 2 records waarvan het ene record Customer.accountid verwijst naar Account.id (database technisch. met hibernate dus customer.account.id). Ook dit kan ik allemaal correct uitlezen als ik de Criteria API gebruik (getest met een lijst van accounts vandaar de id in de request.parameters).

Heeft iemand een idee waarom het hele HQL verhaal niet werkt? Ik zit echt ramvast en heb zo'n beetje alle api docs, forum posts, boeken en zooi gehad en ik kom er echt niet uit.

T is for TANK, and T is for TERROR ... and K is the K for KILLING in error.


  • Cuball
  • Registratie: Mei 2002
  • Laatst online: 03-04 10:15
welke query voert hibernate uit ?

"Live as if you were to die tomorrow. Learn as if you were to live forever"


  • a3konijn
  • Registratie: Oktober 2000
  • Laatst online: 17-04 08:43
Het probleem zie ik zo niet, maar waarom gebruik jij transacties die je vervolgens commit bij een select query?

  • Tubby
  • Registratie: Juni 2001
  • Laatst online: 02:53

Tubby

or not to be

Java:
1
2
3
4
5
6
    public List find(String hql) throws HibernateException 
    {
            Session session = HibernateUtil.getSession();
            Query query = session.createQuery(hql);
            return query.list();
    }

That should be all als alles goed geconfigged is, waarbij hql je query is en HibernateUtil je Session manager met daarin een SessionFactory

En een Transaction is nergens goed voor bij een select query?

[ Voor 8% gewijzigd door Tubby op 12-01-2006 10:24 ]

tubby.nl - Artes Moriendi - q1 - bf1942 - WoT - pubg - LinkedIN


  • Nibble
  • Registratie: Juli 2001
  • Laatst online: 13-04 15:26
@Cuball
Momenteel voert hibernate deze query uit (zie bovenste stuk wat niet uitgecomment is):
Java:
1
   Query hql = hibernateSession.createQuery("from Customer as c"); 


@a3konijn:
Omdat ik graag met transacties werk en er later misschien nog meer bijkomt en ik graag ACID werk :) en als er iets fout gaat wil ik alles netjes terug kunnen rollen.

T is for TANK, and T is for TERROR ... and K is the K for KILLING in error.


  • Tubby
  • Registratie: Juni 2001
  • Laatst online: 02:53

Tubby

or not to be

Nibble schreef op donderdag 12 januari 2006 @ 10:24:
@a3konijn:
Omdat ik graag met transacties werk en er later misschien nog meer bijkomt en ik graag ACID werk :) en als er iets fout gaat wil ik alles netjes terug kunnen rollen.
leuk voor je, maar er valt nix terug te rollen met een select query, alleen bij updates of deletes zou dat interessant zijn

tubby.nl - Artes Moriendi - q1 - bf1942 - WoT - pubg - LinkedIN


  • Cuball
  • Registratie: Mei 2002
  • Laatst online: 03-04 10:15
Nibble schreef op donderdag 12 januari 2006 @ 10:24:
@Cuball
Momenteel voert hibernate deze query uit (zie bovenste stuk wat niet uitgecomment is):
Java:
1
   Query hql = hibernateSession.createQuery("from Customer as c"); 
ik bedoel de query die hibernate genereert en op de db los laat
@a3konijn:
Omdat ik graag met transacties werk en er later misschien nog meer bijkomt en ik graag ACID werk :) en als er iets fout gaat wil ik alles netjes terug kunnen rollen.
gebruik dan spring als je graag met transacties werkt, maar bij een select query is een transactie totaal overbodig

[ Voor 3% gewijzigd door Cuball op 12-01-2006 10:31 ]

"Live as if you were to die tomorrow. Learn as if you were to live forever"


  • Nibble
  • Registratie: Juli 2001
  • Laatst online: 13-04 15:26
Tubby schreef op donderdag 12 januari 2006 @ 10:24:
Java:
1
2
3
4
5
6
    public List find(String hql) throws HibernateException 
    {
            Session session = HibernateUtil.getSession();
            Query query = session.createQuery(hql);
            return query.list();
    }

That should be all als alles goed geconfigged is, waarbij hql je query is en HibernateUtil je Session manager met daarin een SessionFactory

En een Transaction is nergens goed voor bij een select query?
Klopt helemaal, alleen zo staat het dus ook in mijn code.
Java:
1
2
3
4
5
6
7
8
9
10
11
//Verkrijg een sessie en begin een transaction
       hibernateSession = AppSession.getSession();
       myTransaction = hibernateSession.beginTransaction();                        
                
        //Query hql = hibernateSession.createQuery("from Customer c where c.account.id in             (select a.id from Account a where a.id = "+request.getParameter("id")+ ") group by c.account.id");                    
        //Query hql = hibernateSession.createQuery("from Customer c where c.account.id =  "+request.getParameter("id"));

        Query hql = hibernateSession.createQuery("from Customer as c");            
        
        
        customers = hql.list();                  


Jouw Session session = HibernateUtil.getSession(); = mijn AppSession.getSession();
Jouw Query query = session.createQuery(hql); = mijn Query hql en hibernateSession.createQuery
Jouw return query.list(); = mijn hql.list();

Het verschil is ziltch behalve dat het niet in een aparte functie staat in deze.
Transacties zijn hier idd overbodig maar gewoon good practice. Maar dat is voor deze zaak totaal irrelevant en dus heeft mijn interesse momenteel ook even niet.
Update: Even om verdere issues omtrend transactions te voorkomen, ik heb het hele transactioneel eruit gehaald en het resultaat is nog extact hetzelfde. Mijn conclusie is dus dat het inderdaad niet relevant is :P

[ Voor 13% gewijzigd door Nibble op 12-01-2006 10:37 ]

T is for TANK, and T is for TERROR ... and K is the K for KILLING in error.


  • Nibble
  • Registratie: Juli 2001
  • Laatst online: 13-04 15:26
Cuball schreef op donderdag 12 januari 2006 @ 10:30:
[...]

ik bedoel de query die hibernate genereert en op de db los laat

[...]
Nou dat is het probleem, er wordt niet eens een query gegenereerd.
Het enige wat er in de debuglogs staat is:
code:
1
2
2006-01-12 10:40:15 StandardWrapperValve[jsp]: Servlet.service() for servlet jsp threw exception
java.lang.OutOfMemoryError: Java heap space

T is for TANK, and T is for TERROR ... and K is the K for KILLING in error.


  • Cuball
  • Registratie: Mei 2002
  • Laatst online: 03-04 10:15
Nibble schreef op donderdag 12 januari 2006 @ 10:41:
[...]


Nou dat is het probleem, er wordt niet eens een query gegenereerd.
Het enige wat er in de debuglogs staat is:
code:
1
2
2006-01-12 10:40:15 StandardWrapperValve[jsp]: Servlet.service() for servlet jsp threw exception
java.lang.OutOfMemoryError: Java heap space
heb je hibernate logging wel aanstaan ? want nu zie ik enkel een error van je servlet ?

als je log4j gebruikt zet die dan hibernate es op debug

"Live as if you were to die tomorrow. Learn as if you were to live forever"


  • Nibble
  • Registratie: Juli 2001
  • Laatst online: 13-04 15:26
Cuball schreef op donderdag 12 januari 2006 @ 10:48:
[...]


heb je hibernate logging wel aanstaan ? want nu zie ik enkel een error van je servlet ?

als je log4j gebruikt zet die dan hibernate es op debug
Hmz hier moet je denk ik ff wat duidelijker zijn mijn log4j config is:
code:
1
2
3
4
log4j.rootCategory=DEBUG, A1
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%-5p - %m%n


dit zou toch gewoon alles moeten tonen?

T is for TANK, and T is for TERROR ... and K is the K for KILLING in error.


  • Nibble
  • Registratie: Juli 2001
  • Laatst online: 13-04 15:26
Ok even een kleine update, ik ben met de criteria aan de gang gegaan en nu ben ik erachter dat hij dus accountid niet invult. Dit is de code die hij genereert:
SQL:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
select this_.ID as ID6_2_,
       this_.HOME_CONTACTADDRESS as HOME2_6_2_,
       this_.BILL_CONTACTADDRESS as BILL3_6_2_,
       this_.SHIP_CONTACTADDRESS as SHIP4_6_2_,
       this_.FIRST_NAME as FIRST5_6_2_,
       this_.LAST_NAME as LAST6_6_2_,
       this_.MIDDLE_NAME as MIDDLE7_6_2_,
       this_.GENDER as GENDER6_2_,
       this_.DATE_OF_BIRTH as DATE9_6_2_,
       this_.CUSTOMERSTATE as CUSTOME10_6_2_,
       this_.ADDITIONDATE as ADDITIO11_6_2_,
       this_.REVISION as REVISION6_2_,
       this_.ROOTREVISION as ROOTREV13_6_2_,
       this_.ACCOUNTID as ACCOUNTID6_2_,
       account2_.ID as ID11_0_,
       account2_.USERNAME as USERNAME11_0_,
       account2_.ADDITIONDATE as ADDITION3_11_0_,
       account2_.ACCOUNTSTATE as ACCOUNTS4_11_0_,
       account2_.USERPASS as USERPASS11_0_,
       account2_.LEVELID as LEVELID11_0_,
       levels3_.ID as ID9_1_,
       levels3_.LEVELNAME as LEVELNAME9_1_,
       levels3_.LEVELSTATE as LEVELSTATE9_1_
from CUSTOMER this_
left outer join ACCOUNT account2_ on this_.ACCOUNTID=account2_.ID
left outer join LEVELS levels3_ on account2_.LEVELID=levels3_.ID
where this_.ACCOUNTID=?


De sourc aanroep is:
Java:
1
2
3
4
Criteria crit = hibernateSession.createCriteria(Customer.class);
                 crit.add(Restrictions.eq("account.id", "1"));
                 crit.setMaxResults(5); //Restricts the max rows to 5                        .      
customers = crit.list();        


Als ik de bovenstaande SQL code inklop en ik vul voor het ? een 1 in klopt alles. Waaorm pikt hij de parameter niet mee?

T is for TANK, and T is for TERROR ... and K is the K for KILLING in error.


  • Standeman
  • Registratie: November 2000
  • Laatst online: 19:30

Standeman

Prutser 1e klasse

Met wat voor parameters start je je servletcontainer op? Door de query blijkt de jvm uit zijn geheugen te lopen. Dat is dus even kritisch kijken naar het aantal rows waar die query mee terugkomt. Als het er 100.000 zijn ofzo dan kan de standaard heap (64MB geloof ik) nog wel eens te weinig zijn (en vraag je af waarom je bijv. 100.000 rows ophaalt).

Probeer eens wat te stoeien met de -Xms<size> en -Xmx<size> parameters van de JVM waarin je servletcontainer draait..

p.s. Draait je DB ook in een JVM?? Misschien ligt het probleem daar wel (hoewel het dan wel weer vreemd is dat je een servlet exception krijgt)

[ Voor 16% gewijzigd door Standeman op 12-01-2006 11:24 ]

The ships hung in the sky in much the same way that bricks don’t.


  • Nibble
  • Registratie: Juli 2001
  • Laatst online: 13-04 15:26
Standeman schreef op donderdag 12 januari 2006 @ 11:23:
Met wat voor parameters start je je servletcontainer op? Door de query blijkt de jvm uit zijn geheugen te lopen. Dat is dus even kritisch kijken naar het aantal rows waar die query mee terugkomt. Als het er 100.000 zijn ofzo dan kan de standaard heap (64MB geloof ik) nog wel eens te weinig zijn (en vraag je af waarom je bijv. 100.000 rows ophaalt).

Probeer eens wat te stoeien met de -Xms<size> en -Xmx<size> parameters van de JVM waarin je servletcontainer draait..
Nou ik heb de server zelf niet opgezet dat heeft systeembeheer in handen. Maar als ik de query run in de sqleditor van de database krijg ik precies 1 row terug (meer heb ik er momenteel ook niet inzitten) dus de out of memory exception heeft daar niets mee te maken.
Ik moet er even bij vermelden dat die out of memory alleen voorkom met de hql query.
De error die ik bij laatstgenoemde (gebruik makende van de Criteria API) krijg is:
code:
1
2
3
DEBUG - preparing statement
DEBUG - binding '1' to parameter: 2
INFO  - could not bind value '1' to parameter: 2

Hij krijgt dus de account.id niet als parameter gebonden lijkt mij. maar waarom niet?

re: PS: nee de database is firebird.

[ Voor 4% gewijzigd door Nibble op 12-01-2006 11:32 ]

T is for TANK, and T is for TERROR ... and K is the K for KILLING in error.


  • Gert
  • Registratie: Juni 1999
  • Laatst online: 05-12-2025
Ondersteuning van versies zit gewoon built in Hibernate, daar hoef je zelf niet moeilijk voor te doen.

Gebruikmaken van Restrictions.eq("Account", "1") werkt ook niet? Ik kan mij zo verstellen dat Hibernate dan zelf wel de juiste parameter er bij zoekt voor dit object. Is alweer een tijdje geleden dat ik dit gedaan heb. :o

edit:
nog wat

In je query is accountid parameter 1, niet 2.

[ Voor 19% gewijzigd door Gert op 12-01-2006 11:34 ]


  • Nibble
  • Registratie: Juli 2001
  • Laatst online: 13-04 15:26
Gert schreef op donderdag 12 januari 2006 @ 11:32:
Ondersteuning van versies zit gewoon built in Hibernate, daar hoef je zelf niet moeilijk voor te doen.
Klopt, maar ik ben er nog niet helemaal uit hoe dit werkt dus doe ik het voorlopig nog even zo.
Gebruikmaken van Restrictions.eq("Account", "1") werkt ook niet? Ik kan mij zo verstellen dat Hibernate dan zelf wel de juiste parameter er bij zoekt voor dit object. Is alweer een tijdje geleden dat ik dit gedaan heb. :o
Java:
1
2
Criteria crit = hibernateSession.createCriteria(Customer.class);
crit.add(Expression.eq("account.id", 1));

Ik ben even netjes volgens het boek aan het werken en dit is wat ik vind bij Criteria.
edit:
nog wat

In je query is accountid parameter 1, niet 2.
Dat is het vreemde ook ja, ik snap niet hoe hij erbij komt om hem aan 2 te binden :?

T is for TANK, and T is for TERROR ... and K is the K for KILLING in error.


  • Varienaja
  • Registratie: Februari 2001
  • Laatst online: 14-06-2025

Varienaja

Wie dit leest is gek.

Als je nu eerst eens met een eenvoudige query begint, zoals
code:
1
Customer c = (Customer) session.get(Customer.class,new Long(1))

dan weet je in ieder geval of je mapping-file uberhaupt wel klopt.
Gert schreef op donderdag 12 januari 2006 @ 11:32:
Ondersteuning van versies zit gewoon built in Hibernate, daar hoef je zelf niet moeilijk voor te doen.
De versioning van Hibernate is bedoeld om meerdere gebruikers om 1 database op een consistente mogelijk te maken. Niet om meerdere versies van records in bij te houden. (8>

Siditamentis astuentis pactum.


  • Nibble
  • Registratie: Juli 2001
  • Laatst online: 13-04 15:26
Varienaja schreef op donderdag 12 januari 2006 @ 11:41:
Als je nu eerst eens met een eenvoudige query begint, zoals
code:
1
Customer c = (Customer) session.get(Customer.class,new Long(1))

dan weet je in ieder geval of je mapping-file uberhaupt wel klopt.


[...]

De versioning van Hibernate is bedoeld om meerdere gebruikers om 1 database op een consistente mogelijk te maken. Niet om meerdere versies van records in bij te houden. (8>
Kijk hier heb ik wat aan :)
Dat blijkt dus niet helemaal lekker te gaan:
code:
1
could not load an entity: [shogun.hibernate.Customer#1]


Maar ik denk dat die long een integer moet zijn. Als ik ervan maak Customer.class,new Integer(1) krijg ik geen error. Log:
Java:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
DEBUG: Geen SessionFactory Aanwezig
DEBUG: Bezig sessie te openen
DEBUG - opened session at timestamp: 4657415223963648
DEBUG - loading entity: [shogun.hibernate.Customer#1]
DEBUG - attempting to resolve: [shogun.hibernate.Customer#1]
DEBUG - object not resolved in any cache: [shogun.hibernate.Customer#1]
DEBUG - Fetching entity: [shogun.hibernate.Customer#1]
DEBUG - loading entity: [shogun.hibernate.Customer#1]
DEBUG - about to open PreparedStatement (open PreparedStatements: 0, globally: 1)
DEBUG - opening JDBC connection
DEBUG - total checked-out connections: 0
DEBUG - using pooled JDBC connection, pool size: 0
DEBUG - select customer0_.ID as ID6_2_, customer0_.HOME_CONTACTADDRESS as HOME2_6_2_, customer0_.BILL_CONTACTADDRESS as BILL3_6_2_, customer0_.SHIP_CONTACTADDRESS as SHIP4_6_2_, customer0_.FIRST_NAME as FIRST5_6_2_, customer0_.LAST_NAME as LAST6_6_2_, customer0_.MIDDLE_NAME as MIDDLE7_6_2_, customer0_.GENDER as GENDER6_2_, customer0_.DATE_OF_BIRTH as DATE9_6_2_, customer0_.CUSTOMERSTATE as CUSTOME10_6_2_, customer0_.ADDITIONDATE as ADDITIO11_6_2_, customer0_.REVISION as REVISION6_2_, customer0_.ROOTREVISION as ROOTREV13_6_2_, customer0_.ACCOUNTID as ACCOUNTID6_2_, account1_.ID as ID11_0_, account1_.USERNAME as USERNAME11_0_, account1_.ADDITIONDATE as ADDITION3_11_0_, account1_.ACCOUNTSTATE as ACCOUNTS4_11_0_, account1_.USERPASS as USERPASS11_0_, account1_.LEVELID as LEVELID11_0_, levels2_.ID as ID9_1_, levels2_.LEVELNAME as LEVELNAME9_1_, levels2_.LEVELSTATE as LEVELSTATE9_1_ from CUSTOMER customer0_ left outer join ACCOUNT account1_ on customer0_.ACCOUNTID=account1_.ID left outer join LEVELS levels2_ on account1_.LEVELID=levels2_.ID where customer0_.ID=?
Hibernate: select customer0_.ID as ID6_2_, customer0_.HOME_CONTACTADDRESS as HOME2_6_2_, customer0_.BILL_CONTACTADDRESS as BILL3_6_2_, customer0_.SHIP_CONTACTADDRESS as SHIP4_6_2_, customer0_.FIRST_NAME as FIRST5_6_2_, customer0_.LAST_NAME as LAST6_6_2_, customer0_.MIDDLE_NAME as MIDDLE7_6_2_, customer0_.GENDER as GENDER6_2_, customer0_.DATE_OF_BIRTH as DATE9_6_2_, customer0_.CUSTOMERSTATE as CUSTOME10_6_2_, customer0_.ADDITIONDATE as ADDITIO11_6_2_, customer0_.REVISION as REVISION6_2_, customer0_.ROOTREVISION as ROOTREV13_6_2_, customer0_.ACCOUNTID as ACCOUNTID6_2_, account1_.ID as ID11_0_, account1_.USERNAME as USERNAME11_0_, account1_.ADDITIONDATE as ADDITION3_11_0_, account1_.ACCOUNTSTATE as ACCOUNTS4_11_0_, account1_.USERPASS as USERPASS11_0_, account1_.LEVELID as LEVELID11_0_, levels2_.ID as ID9_1_, levels2_.LEVELNAME as LEVELNAME9_1_, levels2_.LEVELSTATE as LEVELSTATE9_1_ from CUSTOMER customer0_ left outer join ACCOUNT account1_ on customer0_.ACCOUNTID=account1_.ID left outer join LEVELS levels2_ on account1_.LEVELID=levels2_.ID where customer0_.ID=?
DEBUG - preparing statement
DEBUG - binding '1' to parameter: 1
DEBUG - about to open ResultSet (open ResultSets: 0, globally: 0)
DEBUG - processing result set
DEBUG - done processing result set (0 rows)
DEBUG - about to close ResultSet (open ResultSets: 1, globally: 1)
DEBUG - about to close PreparedStatement (open PreparedStatements: 1, globally: 2)
DEBUG - closing statement
DEBUG - total objects hydrated: 0
DEBUG - initializing non-lazy collections
DEBUG - done entity load
DEBUG - after autocommit
DEBUG - aggressively releasing JDBC connection
DEBUG - closing JDBC connection [ (open PreparedStatements: 0, globally: 1) (open ResultSets: 0, globally: 0)]
DEBUG - returning connection to pool, pool size: 1
DEBUG - closing session
DEBUG - connection already null in cleanup : no action 


Maar weer die parameter die krom zit in het sql stuk :/ hij lijkt gewoon te ontbreken.
Maar het schijnt dat de parameter pas NA de sql gegenereerd wordt?

[ Voor 64% gewijzigd door Nibble op 12-01-2006 12:15 ]

T is for TANK, and T is for TERROR ... and K is the K for KILLING in error.


  • Gert
  • Registratie: Juni 1999
  • Laatst online: 05-12-2025
Zo werken prepared statements. :)
Je maakt een query, bereidt het voor en vult de parameters in, eventueel kan je ze dan weer verwijderen en nieuwe toevoegen zonder opnieuw de query te hoeven voorbereiden, wat dus een van de voordelen is. ;)
Hibernate zorgt er zelf wel voor dat ze op de juiste plek terecht komen, als alles goed gaat. :o

  • Nibble
  • Registratie: Juli 2001
  • Laatst online: 13-04 15:26
Ja ok, maar nu heb ik nog steeds geen bruikbaar record terug omdat de parameter niet wordt meegenomen...

T is for TANK, and T is for TERROR ... and K is the K for KILLING in error.


  • Varienaja
  • Registratie: Februari 2001
  • Laatst online: 14-06-2025

Varienaja

Wie dit leest is gek.

Nibble schreef op donderdag 12 januari 2006 @ 13:15:
Ja ok, maar nu heb ik nog steeds geen bruikbaar record terug omdat de parameter niet wordt meegenomen...
code:
1
2
3
4
5
DEBUG - preparing statement
DEBUG - binding '1' to parameter: 1
DEBUG - about to open ResultSet (open ResultSets: 0, globally: 0)
DEBUG - processing result set
DEBUG - done processing result set (0 rows)


De parameter wordt wel meegenomen. De query wordt eerst inclusief de vraagtekentjes naar de DB gestuurd, zodat deze z'n borst nat kan maken voor wat er komen gaat. Daarna krijgt de DB de parameter(s) te zien. (Daarmee zorgt de DB ervoor dat ie snel heel veel queries kan doen die exact hetzelfde zijn, op wat parameters na).

Ik zie in je debug-log dat er gewoon geen rij wordt gevonden (0 rows). Probeer eens met een primary key die wel in de DB voorkomt..

Siditamentis astuentis pactum.


  • Nibble
  • Registratie: Juli 2001
  • Laatst online: 13-04 15:26
Varienaja schreef op donderdag 12 januari 2006 @ 13:45:
[...]


code:
1
2
3
4
5
DEBUG - preparing statement
DEBUG - binding '1' to parameter: 1
DEBUG - about to open ResultSet (open ResultSets: 0, globally: 0)
DEBUG - processing result set
DEBUG - done processing result set (0 rows)


De parameter wordt wel meegenomen. De query wordt eerst inclusief de vraagtekentjes naar de DB gestuurd, zodat deze z'n borst nat kan maken voor wat er komen gaat. Daarna krijgt de DB de parameter(s) te zien. (Daarmee zorgt de DB ervoor dat ie snel heel veel queries kan doen die exact hetzelfde zijn, op wat parameters na).

Ik zie in je debug-log dat er gewoon geen rij wordt gevonden (0 rows). Probeer eens met een primary key die wel in de DB voorkomt..
Zojuist gedaan, resultaat:
Java:
1
2
2006-01-12 14:27:23 StandardWrapperValve[jsp]: Servlet.service() for servlet jsp threw exception
java.lang.OutOfMemoryError: Java heap space 

T is for TANK, and T is for TERROR ... and K is the K for KILLING in error.


  • matthijsln
  • Registratie: Augustus 2002
  • Laatst online: 16-04 16:54
Hoe is je hibernate mapping voor Customer en relaties?

  • Varienaja
  • Registratie: Februari 2001
  • Laatst online: 14-06-2025

Varienaja

Wie dit leest is gek.

De query duurt erg lang, en geeft een out-of-memory melding.

HQL-technisch ziet alles er prima uit, ik zou dan zeggen dat je een waarschijnlijk oneindige loop in een van je setters hebt zitten. Ga breakpoints zetten! ;)

Siditamentis astuentis pactum.

Pagina: 1