Entity bean nem veszi fel az adatbázisban beállított default értket.

Java

Sziasztok!

Segítségeteket szeretném kérni, az alábbi problémám megoldásában. Létrehoztam egy adatbázistáblát, ahol bizonyos mezőknek beállítottam default értéket. Amikor new-val példányosítok egy entity-t és aztán EntiyManager-er contextusába helyezem, nem veszi fel a def. értékeket. Én bénázhattam el valamit? vagy ez így nóórmális?

Köszi a segítő válaszokat előre is.

  • 1341 megtekintés

( NagyZ v | 2009. 10. 21., sze – 15:19 )

ez olyan, mint az id esete: a dbbol jon, az EM retegtol fuggetlenul.

nezd meg egy persist, flush, refresh utan.

A táblában a mező így néz ki:`new` int(4) NOT NULL DEFAULT '1'
ebből netbeans segítségével generálom az entitást, ami így néz ki: @Column(name = "new")
private Integer new;
A végeredményt pedig közvetlenül az adatbázisban nézem, és 0-lesz az értéke a mezőnek :(

szerk.: én azt várnám ha nem állítok be semmit, mivel not null, hogy dob egy nullpontexception-t de nem

.:LISA PHP Framework:.

( kispista | 2009. 10. 21., sze – 15:23 )

Nem vagyok pro EE-ből, de ez mit takar: "new-val példányosítok egy entity-t és aztán EntiyManager-er contextusába helyezem" ? merge, delete, persist? @Column(columnDefinition="")-ben próbáltad állítani a defval-t? Entity kódját megoszthatnád, az többet elárulhat.

A kódrészletet fentebb postoltam. A helyzet, hogy meglévő adatbázisból generálom az entitásokat, és persze beletehetném az említett sort, de klényelmesebb volna, ha a fejlesztés iránya továbbra is db2entity maradna és a default értékek is bekerülnének.

.:LISA PHP Framework:.

( mhmxs v | 2009. 10. 21., sze – 16:43 )

Hogy ne csak a levegőbeb eszéljek az sql itt:
CREATE TABLE IF NOT EXISTS `properties` (
`id` mediumint(9) NOT NULL AUTO_INCREMENT,
`received` datetime NOT NULL,
`status` int(5) NOT NULL DEFAULT '1000',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=5 ;

A generált kód pedig itt

Köszi
.:LISA PHP Framework:.

Azt a kollégám vetette fel egyidőben velem, csak megért a hupon is kérdezzem meg hátha előbb jön a válasz :D és nem hiszem, hogy félrebeszélés menne (eltekintve az összelapátolt példakódtól), szerintem egyértelmű a probléma, és a ki már talákozott vele tudja is a választ.

.:LISA PHP Framework:.

nem az enyem, a Concurrency in Javabol van. :)
ugyanis az tortenik osztalyletrehozaskor, hogy a fieldek inicializalodnak a default ertekkel, majd _utana_ lefut a konstruktor.

igy ha ido elott adod oda az osztalyt mondjuk egy szalnak, akkor siman lehet, hogy mikor meghivja a metodust, elobb kiolvassa a default erteket (intnel ez 0), majd a masodik kiolvasasra mar a jo erteket kapod :)

en is csak neztem.

[a melyebb okok az, hogy mutable objektumok publishelodnek a konstruktor lefutasa elott, immutable objektumok meg vagy fully constructedok mar mikor publisholodnak, vagy nem publisholodnak. ha a fieldet finalnak deklaraljuk, mar el is kerulheto ez a hiba, mert akkor mar ugye immutable lesz az osztaly].

(bocs a hunglishert, ezert irom angolul a diplomamunkam, mert ilyeneket en aztan nem fogok leforditani.)

Ez azért csak akkor igaz, ha a származtatott konstruktoron belül (szerk, most elolvastam újra, ezt írtad úgy hogy "idő előtt") elrakod a példány referenciáját valahova, ahol egy másik thread is ki tudja olvasni (ha már az X konstrukturában nem is teszel ilyent). Biztosan van ilyen eset, de azért ez brutális megoldás bármilyen alap-problémára.

Amúgy hogyan jött az adatbázisos threadhez? :)

hogy itt is a default initialization miatt nem safe a publishing, es a kollega is a default value miatt szivta be, hogy a db nem csapta felul az ott definialt valueval :-)

amugy ha egyik diakom/kollegam ilyen kodot ir, es nem rakja finalra szerencsetlen fieldet, akkor jol letorom a kezet. ugyis konstruktorbol jon, ugysincs mas, akkor minek mutable object? raadasul legalabb reusable lesz. :)

Akkor a refresh gyakorlatilag egy uj objektummal csapja felul az eredetit? Vagy nem ertem... ha final-ra rakom, akkor elvben mar nem modosithato, viszont ha egy objektumot refresh-elek, az elvben modositja az osszes erteket, tekintet nelkul arra, hogy tartalmazza-e mar az illeto field a jo erteket, nem?
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

entity bean amugy sem lehet final, szoval az itt buko (a JPA nem tudja kitalalni a helyes konstruktorparametereket, AFAIK).

de mar megint kevered a szezont a fazonnal: itt arrol volt szo, hogy fog egy nem final primitive-type fieldes POJOt, persisteli, es csodalkozott, hogy miert nem a dbben levo default ertek hajtodik vegre. ha megnezte volna a kimeno sqlt, hogy marpedig ott ez a mezo is bekerul persistnel, meghozza 0 ertekkel (ami az int defaultja), akkor ne mkerdezte volna meg. :)

en entitykben mindig azt mondom, hogy ne hasznaljunk primitiv tipusokat.