Fórumok
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.
Hozzászólások
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:.
?? szerinted a new lehet field neve???????
(utalom a sok kerdojelet, de ez olyan szintu java tudast feltetelez, hogy....)
:D ezt már sose mosom le magamról.. sajnos a példát összeollóztam, mivel a kolléga (aki a problémába ténylegesen belefutott) lemet cigizni, az adatbázissor egy PHP-s projectből származik :(
.:LISA PHP Framework:.
Ez az osztály hogy fordult le neked (private Integer _new_)?
mar a generalas is bug, mindjart nyitok rola egy bugreportot.
szerk: ha osszevan ollozva, akkor nem nyitok.
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.
new utan te deletet szoktal?
igazad van, visszaszívom.
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:.
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:.
Itt legalabb nem a mellebeszeles folyik. En is beleutkoztem ebbe. Az entity bean konstruktoraban beallitod az erteket.
itt nem beszeltunk melle. en feldobtam egy hasznalhato kerdest, amire azota se kaptam valaszt.
ha db szinten vannak definialva a def valuek, akkor refresh utan bizony vissza fognak olvasodni.
Hidd el 0-ákkal lesz tele a db ahol nem adok meg int-nek értéket, és nem refressel néztem, hanem közvetlen lekérdeztem az adatbázist.
.:LISA PHP Framework:.
en elhiszem, de erre lasd lent a valaszt, h primitiv tipusoknak van default erteke.
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:.
private int status;
vs:
private Integer status;
Utóbbi esetben van esélyed a default value-ra, előbbi esetben mindig nem-null (maximum 0) értéked van. Szóval amíg ott int van, addig mindig írsz valamit a db-be, nem jön szóba a default value.
erre egy jo pelda az, hogy vajon a kovetkezo kod dob-e exceptiont, es ha igen, miert?
osszad meg tudásod.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
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?
--
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.
Aham, most mar ertem, koszonom a korrekciot.
--
nem? :)
ugy kellett volna fogalmaznom, hogy dobhat-e.. :)
En is odaereztem a 'can' -t...
--
Köszönöm szépen mindenkinek, értem a problémát, tanultam is belőle.
.:LISA PHP Framework:.