數據庫應用中,很多查詢結果中的記錄條數是很多的.如果一次取出返回給客戶,會造成很大的問題.人們解決這個問題的方法就是分頁.
java中最基礎的jdbc 層,Resultset中,可以使用absolute()方法定位記錄位置----記錄的遊標等類型是否要求滑動的,需要再確認.另外getRow()方法返回當前遊標所在行號,從0開始計數. last()配上getRow()可以獲取此次查詢後得到的行數.
關於jdbc的使用,原先考慮過跨層之間傳數據的問題,因爲Resultset是有連接的,所以不適合用來傳數據.中間想到把resultset轉換成xml或其他的對象(比如pojo).本來想手工做,但後來研究發現,其實jdbc提供了更方便的方法.那就是RowSet接口,ResultSet可以把結果保存到 CachedReowset 這之類的對象中, 這些對象是無連接的,可以用作層之間傳遞大宗數據. 甚至好像還可以自動把Resultset直接 保存到xmlRow中吧,需要再確認了.
可見,有了rowset接口以後,至少可以省去手工把resultset 轉換成其他比如bean 中的麻煩,但是這種自動轉換的rowset 是否具有某種缺點或需要注意的地方,那就需要使用的時候再研究了.
在hibernate中也有比較方便的分頁方法.session.createQuery() 以後得到的query接口中有setFirstResult() 和setMaxResults() 兩個方法,可以實現分頁. 如果再實現一個特別的類,在類中記錄curPage,pageLen,然後通過計算,需要的時候再次從query中查詢,就會比較方便的得到分頁的功能了.只是要再專門的寫類和方法才行,需要且也值得專門設計一下.
使用hibernate作爲數據訪問層,只能解決某些問題,對那些單個實體表和類的操作,確實非常簡單,使用工具生成代碼,甚至都不需要自己寫代碼. 但是對於複雜的連接查詢(在實際的應用中非常多),其實hibernate是不能很好支持的.即使可以進行對象之間的一對一,多對多之類的映射,但象我之前寫慣了sql的應用者,總覺得直接用sql來的快和省事.況且,很多複雜的連接查詢,也沒有辦法用映射解決的.那些查詢的條件有時候都要寫好幾行,你想,要是用映射怎麼來表示呢? 本來的想法是使用hibernate的connection對象或者乾脆做一獨立的jdbc訪問模塊,和hibernate並列或者在hibernate的上面.經過研究之後又發現,hibernate提供了native sql的功能.可以使用session.createSQLQuery() 獲得SQLQuery接口,然後通過配合 addScalar() 方法,可以獲得一個對象列表. 這種方法也沒有仔細研究呢,但這至少提供了一個方法,
需要進一步研究,到底是使用sqlQuery 還是直接使用session 的jdbc connection, 研究後再確定吧.
原生的sql語句還沒有真正使用過,但是看的有些資料好像說不能查詢沒有映射的實體.如果是這樣,那還是不夠靈活,也不能滿足我的特殊需求了.
這些只是思路,還沒有設計出具體的方案,以後有時間再總結吧.
++++++++++++++++++++++++
在修改divs (和偶爾的channels修改也會遇到)時,遇到雖然調用了dao的update方法(save也一樣),但是沒有執行update操作到數據庫,後來發現這是與manytoone 或 onetomany 有關的.如果在pojo中,有這兩個關聯,則需要小心處理更新的問題.我的divs類的情況是這樣的,其中有一個manytoone到channels的關聯,有了這個關聯後,可能是後來我自己又爲了方便還是怎麼地,加了一個 channId的屬性,導致這個類沒有辦法更新,而且還不報錯,直到後來在onetomany下加了 @org.hibernate.annotations.Cascade(org.hibernate.annotations.CascadeType.SAVE_UPDATE),再執行更新時,就打出update語句,原來是多出一個channid的屬性設置--在update的set子句中.
看看這個夠複雜吧,manytoone的屬性,又跟onetomany搞上關係,真是雲裏霧裏,現在我通過刪除後來加上的channId屬性,解決了這個問題,但是其實其中道理,還不是太明白的.大概要好好看看hibernate的內部機制才行, 這個還是應該值得研究一下的.
--hibernate reference 介紹 xml 的使用.可以看看.