Tak po dnesni noci jsem realista:) Ale zaujala me docela moznost napsat si na to aspekt. Na to se jeste podivam:)
S pozdravem, Petr Gola On 6/6/06, Jiří Melichna <[EMAIL PROTECTED]> wrote:
Preji vsem hezky den, koukam, ze zpusob vlozeni zaznamu do RDBMS je tak trochu filozoficka uvaha a vidim, ze jsou dva az tri tabory: - tabor 1 (dle meho nazoru hazarderi): Vlozit naslepo a cekat na pripadnou vyjimku - tabor 2 (realiste): Provest kontrolu (validaci dat) a pak vlozit (s ocekacekavanim pripadne vyjimky v napr v pripade nasazeni v clusteru) - mimochodem se ve vasem pripade urcite neprochazi vse, ale velmi selektivne dle unikatniho klice, ktery bude podporen indexem - tabor 3 (nejvetsi pesimiste): Zamknout tabulku na urovni DB, provest kontrolu a vlozit - napr. vyuziti API s ulozenymi procedurami Jsem zvedav, ktery tabor zvitezi... Ja osobne jsem spise realista az pesimista. Co se tyce business vyjimek napr. na existenci uzivatele, urcite bych provedl nejprve validaci na urovni provedeni dotazu do RDBMS - jiz DAO by generovalo svou exception - obesel bych nutnost deklarovat transakci na DAO, mel bych spravnou abstrakci vyjimky na vsech urovnich, byla by poskytnuta vhodna vyjimka pro rollback v transakcnim manazeru, ze SQL kodu chyby bych slozite nelouskal problem s constraintem a nemusel toto resit pro vice ruznych DB. Konec koncu ona DataIntegrityViolationException je hodne obecna a Spring ji vraci na kde co a tak se podle meho nehodi pro vyse zmineny postup. Mimochodem exception je napr. v RDBMS Oracle pomerne draha operace - vetsinou narocnejsi nez overeni existence zaznamu dle unikatniho klice. melichnj > ------------ Původní zpráva ------------ > Od: Petr Gola <[EMAIL PROTECTED]> > Předmět: Re: Spam:Re: Spring+Hibernate - obsluha vyjimek databaze > Datum: 05.6.2006 22:53:15 > ---------------------------------------- > No, pokud bych zavedl do aplikace i validaci vstupnich dat, tak bych > musel pri pridavani kazdeho dalsiho zaznamu precist vsechny zaznamy v > databazi a zkontrolovat, jestli uz tam nejaky zaznam se stejnym > username neexistuje. Hm, asi je to jedina moznost - ale stejne me > porad vrta hlavou, jestli se to neresi jinak... :) > > S pozdravem, Petr Gola > > On 6/5/06, Michal Palička <[EMAIL PROTECTED]> wrote: > > > > Dobry den, > > > > domnivam se, ze systematictejsi by bylo zavest do aplikace krome validace > vstupnich dat (formatu) > > take validaci na urovni dat. V teto fazi by se kontrolovala korektnost vstupu > vzhledem k omezenim, > > ktera vyplyvaji z logiky datoveho modelu. > > > > Ve vasem pripade jde napr. o pozadavek na jedinecnost jmen uzivatele. > > > > Muze se stat, ze jednou zmenite databazi anebo prejdete na novejsi verzi > knihovny Spring > > anebo zcela zmenite pouzitou technologii - a vyjimky budou vypadat uplne > jinak... > > > > mp. > > > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Petr Gola > > Sent: Monday, June 05, 2006 7:50 PM > > To: Java > > Subject: Spam:Re: Spring+Hibernate - obsluha vyjimek databaze > > > > Mockrat dekuji. > > > > Mam jeste jeden dotaz. Pokud obsahuje zaznam vice unique polozek - jsem > schopen z vyjimky nejak zjistit, ktera "constraint" je duvodem? > > Pripadne jak? > > > > Vsiml jsem si na vystupu: > > (util.JDBCExceptionReporter 72) ERROR: duplicate key violates > > unique constraint "catalog_users_username_key" > > > > Jak bych se mohl dostat k temto udajum programove? Abych primo v metode > userDAO.saveUser(User usr) mohl zjistit, co bylo pricinou chyby (v tomto pripade > poruseni kotvy catalog_users_username_key) a na zaklade toho pokracovat? > > > > On 6/5/06, Kamil Podlesak <[EMAIL PROTECTED]> wrote: > > > Petr Gola wrote: > > > > > > > Bohuzel, stale se nemohu dobrat k vysledku. > > > > > > > > > Pricina je ta, ze Hibernate neprovede operaci v databazi ihned, ale az > > > pri ukonceni transakce (to je defaultni chovani), kdy se pokusi > > > provest vsechny zmeny najednou. V tomto pripade je pouzito Spring AOP, > > > kdy se commit provede pri ukonceni metody (viz ten stack trace) - a v > > > tom okamziku se vygeneruje vyjimka. Takze try-catch block uvnitr > > > samozrejme nic nechyti. > > > > > > Resenim je provest flush explicitne: > > > getHibernateTemplate().flush() > > > > > > Take se da Hibernate nakonfigurovat aby flushoval vzdy, ale to ma > > > smysl jen pokud takovych situaci bude vice (a pak by mozna nebylo od > > > veci zamysleni, proc je business logika v databazi pod ORM). > > > > > > > implementace DAO: > > > > > > > > public class UserHibernateDAO extends HibernateDaoSupport implements > > > > IUserDAO { public User saveUser(User usr) { > > > > getHibernateTemplate().saveOrUpdate(usr); > > > > return usr; > > > > } > > > > ... > > > > } > > > > > > > > SLUZBA: > > > > > > > > public class UserSpringService implements IUserService { private > > > > IUserDAO userDAO; > > > > > > > > public User saveUser(User usr) { > > > > try { > > > > usr = userDAO.saveUser(usr); > > > > } catch (DataAccessException daex) { > > > > System.out.println("daex:"+daex); > > > > throw new ExistingUsernameException("Existing username!"); > > > > } > > > > return usr; > > > > } > > > > ... > > > > } > > > > > > > > No, bohuzel nevim, kde je problem, ale zadna > > > > ExistingUsernameException vyhozena neni, Tomcat vypise: > > > > > > > > (def.AbstractFlushingEventListener 300 ) Could not synchronize > > > > database state with session > > > > org.hibernate.exception.ConstraintViolationException: Could not > > > > execute JDBC batch update at > > > > org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter. > > > > java:71) > > > > > > > > at > > > > org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHel > > > > per.java:43) > > > > > > > > at > > > > org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java > > > > :202) at > > > > org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:235 > > > > ) at > > > > org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:139 > > > > ) > > > > at > > > > org.hibernate.event.def.AbstractFlushingEventListener.performExecuti > > > > ons at org.hibernate.event.def.DefaultFlushEventListener.onFlush > > > > at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:985) > > > > at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:333) > > > > at > > > > org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.jav > > > > a:106) > > > > > > > > at > > > > org.springframework.orm.hibernate3.HibernateTransactionManager.doCom > > > > mit at org.springframework.transaction.support.AbstractPlatform... > > > > at > > > > org.springframework.transaction.support.AbstractPlatformTransactionM > > > > anager.commit > > > > > > > > at > > > > > org.springframework.transaction.interceptor.TransactionAspectSupport.doCommit... > > > > > > > > at > > > > org.springframework.transaction.interceptor.TransactionInterceptor.i > > > > nvoke at > > > > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed > > > > at org.springframework.aop.framework.JdkDynamicAopProxy.invoke > > > > at $Proxy1.saveUser(Unknown Source) > > > > > > > > Ale pokud zavolam z klienta volam > > > > try { userService.saveUser(usr) } catch(DataAccessException daex) ... > > > > dostanu > > > > > > > > daex:org.springframework.dao.DataIntegrityViolationException: > > > > Hibernate operation: Could not execute JDBC batch update; SQL > > > > [insert into ... > > > > > > > > Ale chtel bych tuto vyjimku osterit uz na strane serveru. > > > > > > > > > > > > > -- > > > Kamil Podlesak <[EMAIL PROTECTED]> > > > > > > > > > > >
