aby rec nestala .)

NHibernate 2.1 released
NHibernate Linq 1.0 released
Fluent NH 1.0 RC

JIMMYJAMES: enum by melo jit namapovat pomoci vlastni implementace IUserType. pokud ale nechces udrzovat ty prvky enum na 2 mistech a pokud chces v DB osetrit integritu, tak ti asi nezbyde nez vyrobit na ty role tabulku a v aplikaci v DB vrstve potom nekde implementovat neco jako GetReziserRole() apod..

JIMMYJAMES: Hibernate neznam, ale ten enum by urcite sel predelat na tabulku, ne? Ta by pak mela vychozi obsah (reziser, herece, osvetlovac, atd...).

Zdravím,
neví někdo jak na ternární asociaci v Hibernate/JPA (používám anotace)?

Mám tuto situaci; eviduju filmy a u nich lidi, kteří se podíleli na jeho tvorbě (tzn. režiséři, scénáristi, herci... nazývám jako "role"). Každý film může mít více lidí stejné role, každý člověk může mít více rolí, každý člověk může být u více filmů.

V databázi to vypadá takto:
Movie (MOVIE_ID, released, runtime, ...);
People (PEOPLE_ID, name, ...);
Movie_people (MOVIE_ID, PEOPLE_ID, role); UNIQUE (MOVIE_ID, PEOPLE_ID, role);

Role je v Hibernate jako Enum. (Nevím, jak synchronizovat Enum v aplikaci s číselníkovou tabulkou či enumem v DB (a nehci to definovat zvlášť na dvou místech), takže momentálně to mám tak, že role je v DB jen číselná hodnota, není FK. Mimochodem, kdyby někdo znal lepší řešení, tak určitě vítám, z databázového pohledu se mi tohle nelíbí.)

Chtěl bych to namapovat nějak takto:
Map<Role, Set<People>> people

Role je Enum type, People doménová třída (@Entity).

Cílem je, abych mohl jednoduše zavolat:
Collection<People> getPeople(Role role);
addPeople(Role role, Collection<People> people);

Už jsem strávil několik hodin hledání, našel jsem i stejný problém v několika diskuzích, ale nikdo to nedokázal vyřešit (ale zatím nikdo nevyloučil, by to nešlo...).

NHLambdaExtensions
A project that provides extension methods for the NHibernate ICriteria interface to allow use of typesafe lambda expressions.

e.g.,

.Add(Expression.Eq("Name", "Smith"))

becomes

.Add<Person>(p => p.Name == "Smith")

Fluent NHibernate - Fluent, XML-less, compile safe, automated, testable mappings for NHibernate. sikovna vec...

JENIIK: ale klidne komentuj - rad se dovzdelam... asi ti vlastne vadi to, ze ten ORM nespusti "update x set value = value + 10 where id in (1,2,3)", ale misto pusti 3 updaty samostatne, co? ale to mi pri odpojenejch datech (jak uz asi naznacoval TENCOKACI) bez dlouhyho pesimistickyho zamykani neprijde zrovna na skodu... bez zamku by to s tim jednim hromadnym updatem mohlo mit celkem neblahy dusledky :)
ale sem dneska uz trochu mimo, tak je mozny, ze sem neco zcela zasadniho prehlid .)

BUTHRAKAUR: To asi nemá cenu komentovat...

JENIIK: nevim ted, co presne ti prijde nenormalni :) ty updaty se odeslou hromadne az pri flushnuti session v jedny davce, takze by v tom nemel bejt zadnej vykonnostni problem....

to jsem moc nepochopil, snad večer se k tomu budu moci vrátit...

JENIIK: jj, to taky pouzivame. ale uklada se to spolecne s tim jednim zaznamem v transakci.

model: uzivatel na polozce dokladu zmeni produkt. po zmene hodnoty v zaznamu polozky se nactou urcite vlastnosti produktu ( podle nejakeho pravidla ) a vytvori se podle nich vlastnosti polozky. pri ukladani zaznamu se pak ulozi do svazane tabulky s vlastnostmi polozky nove zaznamy.

takze vysledek je nejaky takovyto (zjednodusene):

UPDATE tblDokladyPolozkaProdukt SET IDProdukt = 'aeb32810-04f7-4516-80fa-8f63d783c885'
DELETE tblDokladyPolozkaVlastnost WHERE IDPolozka = '91a41310-58ea-49b1-be5d-64270f11abbe'
INSERT INTO tblDokladyPolozkyVlastnist ( VlastnostID, IDPolozka, IDDruhVlastnosti, Vlastnosti ) VALUES ( ............. )

Takhle se to normalne dela, pokud mas scenar s "odpojenymi daty". Kdyz to spravne implementujes tak, mas jistotu ze se ti bud ulozi vsechno nebo nic.

TENCOKACISTROMY: no to jo, ale to, co jsem viděl dole mělo simulovat mlj trigger a to dost nešťastně. Totiž změnou jednoho záznamu můžeš změnit X záznamů ve statistických tabulkách...

JENIIK: nerozumime si.
Uzivatel v UI vidi tabulku s X zaznamy. z tech X zanamu jich Y upravi, coz spusti dalsich Z uprav jinde. kazda uprava je "originalni" ve smyslu ze kazdy z tech upravovanych zaznamu ma zmeneny ruzny sloupce a v nich ruzne hodnoty.

jak to udelat jinak nez nekolik update prikazu do sql?

TENCOKACISTROMY: update něco=něco+něco_jiného where cosi=cosi_jiného

???

JENIIK: znas lepsi reseni jak updatovat data z UI do DB?

BUTHRAKAUR: tohle myslíš vážně? poslat na DB stroj hromadu updatů postupně za sebou? To mi nepřijde optimalizované. Je to hezké pro programátora, server se na to bude tvářit trošku jinak ;-)

nebo se snad z toho for each vygeneruje jeden dotaz?

BUTHRAKAUR: Pochopitelně hranice mezi tím co je aplikační logika a co logika ukládání dat je mlhavá. Někde vést řez musíš a umění vedení tohoto řezu je také to, za co tě platěj. Ostatně já nemám pojem "business logika" rád, on vytváří dojem, že je snad součást aplikace která není business logikou. Přitom to, zda řádek v tabulce bude při splnění nějaké podmínky zelený či červený je čistě view, ale není to i business? A podobně i směrem k datům: je požadavek na rychlé redundantní tabulky v nenormalizovaném tvaru business, nebo není?

BUTHRAKAUR: a co je spatny na hybridu :)? imho to je docela efektivni cesta.

TENCOKACISTROMY: to ja vim. to uz ale potom nemluvime o ciste ORM-powered reseni, ale o SP, pripadne nejakym hybridu..