Vra

Met betrekking tot my vorige vraag, Ek wil verseker dat al die kindervoorwerpe gelaai word aangesien ek 'n veelvuldige drade het wat dalk toegang tot die data moet kry (en dus lui laai-uitsonderings vermy).Ek verstaan ​​die manier om dit te doen is om die "haal" sleutelwoord in die navraag te gebruik (EJB QL).Soos hierdie:

select distinct o from Order o left join fetch o.orderLines

Gestel 'n model met 'n Order klas wat 'n stel van het OrderLines daarin.

My vraag is dat die "afsonderlike" sleutelwoord nodig blyk te wees, want anders lyk dit of ek terug 'n Order vir elke OrderLine.Doen ek die regte ding?

Miskien nog belangriker, is daar 'n manier om alle kindervoorwerpe in te trek, maak nie saak hoe diep nie?Ons het ongeveer 10-15 klasse en vir die bediener sal ons alles moet gelaai ...Ek het vermy om te gebruik FetchType.EAGER aangesien dit beteken dat dit altyd gretig is en veral die webvoorkant laai alles - maar miskien is dit die pad om te gaan - is dit wat jy doen?Dit lyk asof ek onthou dat ons dit voorheen probeer het en toe baie stadige webblaaie gekry het - maar miskien beteken dit dat ons 'n tweedevlakkas moet gebruik?

Was dit nuttig?

Oplossing

Om die aantekening te verander is 'n slegte idee IMO.Aangesien dit nie tydens looptyd na lui verander kan word nie.Beter om alles lui te maak, en haal soos nodig.

Ek is nie seker ek verstaan ​​jou probleem sonder kartering nie.Linkeraansluiting haal moet al wees wat jy nodig het vir die gebruiksgeval wat jy beskryf.Natuurlik sal jy 'n bestelling terugkry vir elke bestellyn as bestellyn 'n bestelling as sy ouer het.

Ander wenke

Ek is nie seker oor die gebruik van die haal sleutelwoord in jou EJBQL nie, jy kan dit dalk verwar word met die annotasie ...

Het jy al probeer om die FetchType-eienskap by jou verhoudingskenmerk te voeg?

@OneToMany(fetch=FetchType.EAGER)?

Sien:

http://java.sun.com/javaee/5/docs/api/javax/persistence/FetchType.html http://www.jroller.com/eyallupu/entry/hibernate_exception_simultaneously_fetch_multiple

Het jy al probeer om 'n resultaattransformator te gebruik?As jy Kriteria-navrae gebruik, kan jy 'n resultaattransformator toepas (alhoewel daar is 'n paar probleme met paginering en resultaat transformator):

Criteria c = ((Session)em.getDelegate()).createCriteria(Order.class);
c.setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY);
c.list();

die em.getDelegate() is 'n hack wat net werk as jy hiberneer gebruik.

Miskien nog belangriker, is daar 'n manier om alle kindervoorwerpe in te trek, maak nie saak hoe diep nie?Ons het ongeveer 10-15 klasse en vir die bediener benodig ons alles gelaai ...Ek het vermy om FetchType.aver te gebruik, want dit beteken dat dit altyd gretig is, en veral die webfront laai alles - maar miskien is dit die manier om te gaan - is dit wat u doen?Dit wil voorkom asof ek onthou dat ons dit al voorheen probeer het en dan regtig stadige webblaaie gekry het - maar miskien beteken dit dat ons 'n tweede -vlak -kas moet gebruik?

As jy nog belangstel, het ek 'n soortgelyke vraag in hierdie draad geantwoord hoe om hiberneer versamelings te serialiseer.

Basies gebruik jy 'n nut genaamd dozer wat boontjies op 'n ander boontjie karteer, en deur dit te doen, aktiveer jy al jou lui vragte.Soos jy jou kan voorstel, werk dit beter as alle versamelings gretig afgehaal word.

Jy kan dalk so iets doen deur 'n (losstaande) kriterianavraag te gebruik en die haalmodus te stel.Bv.

Session s = ((HibernateEntityManager) em).getSession().getSessionFactory().openSession();
DetachedCriteria dc = DetachedCriteria.forClass(MyEntity.class).add(Expression.idEq(id));
dc.setFetchMode("innerTable", FetchMode.JOIN);
Criteria c = dc.getExecutableCriteria(s);
MyEntity a = (MyEntity)c.uniqueResult();

Dit sal net vir ManyToOne-verhoudings werk en vir hulle sal @ManyToOne(fetch=FetchType.EAGER) waarskynlik toepaslik wees.

Om meer as een OneToMany-verhouding gretig te gaan haal, word ontmoedig en/of werk nie soos jy kan lees in die skakel wat Jeremy geplaas het nie.Dink net aan die SQL-stelling wat nodig sal wees om so 'n ophaal te doen ...

Wat ek gedoen het, is om die kode te herfaktoreer om 'n kaart van voorwerpe aan entiteitbestuurders te hou en elke keer as ek moet verfris, maak die ou entiteitbestuurder vir die voorwerp toe en maak 'n nuwe een oop.Ek het die bogenoemde navraag gebruik sonder die haal aangesien dit te diep gaan vir my behoeftes - om net 'n plain join te doen, trek die OrderLines in - die haal laat dit nog dieper gaan.

Daar is net 'n paar voorwerpe waarvoor ek dit nodig het, ongeveer 20, so ek dink die hulpbronbokoste om 20 oop entiteitbestuurders te hê, is nie 'n probleem nie - alhoewel die DBA's 'n ander siening kan hê wanneer dit in werking tree ...

Ek het ook dinge herwerk sodat die db-werk op die hoofdraad is en die entiteitbestuurder het.

Chris

As die probleem net LazyInitializationExceptions is, kan jy dit vermy deur 'n OpenSessionInViewFilter by te voeg.
Dit sal toelaat dat die voorwerpe in die aansig gelaai word, maar sal nie help met die spoedkwessie nie.

     <filter>
        <filter-name>hibernateFilter</filter-name>
        <filter-class> org.springframework.orm.hibernate3.support.OpenSessionInViewFilter
        </filter-class>
    </filter>
    <filter-mapping>
        <filter-name>hibernateFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
Gelisensieer onder: CC-BY-SA met toeskrywing
Nie verbonde aan StackOverflow
scroll top