timelyxyz

@Entity

public class ClassOne {

public String id;

}

public class ClassTwo {

@ManyToOne

public ClassOne classOne; // 父表

}

outer-join     fetch     lazy         主鍵表class     檢索策略         檢索方式
true/false/auto     select     false         true/false     立即檢索（n+1次查詢）     所有
-         -     no-proxy/proxy     true         延遲檢索         所有
-         -     -         false         立即檢索（n+1次查詢）     所有
-         join     false         true/false     inner join         QBC，get()/load()
-         -     -         -         立即檢索（n+1次查詢）     HQL，NativeSQL
-         join     no-proxy/proxy     false         inner join         QBC，get()/load()
-         -     -         -         立即檢索（n+1次查詢）     HQL，NativeSQL
-         -     -         true         inner join         QBC，get()/load()
-         -     -         -         延遲檢索




String hql = "select t,count(tp) from ContentTag_Post as tp     left join fetch tp.tag as t"
    + " where tp.tag=t and t.owner.id=? "
    + " and tp.isDeleted=false and t.isDeleted=false "
    + " group by t order by t.createTime desc ";


        String hql = "select t,count(tp) from ContentTag as t left join ContentTag_Post as tp "
                + " where t.owner.id=? and t=tp.tag "
                + " and t.isDeleted=false and tp.isDeleted=false "
                + " group by t order by t.createTime desc ";

 Path expected for join!
2012-08-22 12:47:37 [ERROR]  Invalid path: 'tp.tag'
right-hand operand of a binary operator was null
<AST>:0:0: unexpected end of subtree
left-hand operand of a binary operator was null


select查詢 join查詢

@LazyToOne用法
http://docs.jboss.org/hibernate/annotations/3.4/reference/zh_cn/html/entity.html
Java中的transient，volatile和strictfp關(guān)鍵字
http://www.iteye.com/topic/52957
transient
  Java語言的關(guān)鍵字，用來表示一個域不是該對象串行化的一部分。當一個對象被串行化的時候，transient型變量的值不包括在串行化的表示中，然而非transient型的變量是被包括進去的


class A implements Serializable {
 private String name;
 transient private String address;
}

那么你在串行化（IO流等）A類時 給它的name和address屬性賦值，那么你在提取A時，拿到了name屬性，但是卻拿不到address屬性。




lazy是延時的意思，如果lazy=true，那么就是說數(shù)據(jù)庫中關(guān)聯(lián)子表的信息在hibernate容器啟動的時候不會加載，而是在你真正的訪問到字表非標識字段的時候，才會去加載。
反之，如果lazy=false的話，就是說，子表的信息會同主表信息同時加載。
一般用只有完全用到子表信息的時候，才會lazy=false

join 查詢的時候，是用以條語句查處所有記錄，包括關(guān)聯(lián)表記錄，select查出的是N+1條記錄，兩個都是差不多的，但是如果用了lazy=true，延遲加載的話，select在查詢時只會查出主表記錄，也就是1，如果其他地方也用到了數(shù)據(jù)，此時就會自動在執(zhí)行查詢，查出N，可以降低內(nèi)存消耗 .還有，hibernate是的session是輕量級的，創(chuàng)建和銷毀都不花很多資源，查詢數(shù)據(jù)也很快，這里fetch主要起這個作用    

Path expected for join! unexpected end of subtree

File(String pathname)

路徑名字符串與抽象路徑名之間的轉(zhuǎn)換與系統(tǒng)有關(guān)。將抽象路徑名轉(zhuǎn)換為路徑名字符串時，每個名稱與下一個名稱之間用一個默認分隔符 隔開。默認名稱分隔符由系統(tǒng)屬性 file.separator 定義，可通過此類的公共靜態(tài)字段 separator 和 separatorChar 使其可用。將路徑名字符串轉(zhuǎn)換為抽象路徑名時，可以使用默認名稱分隔符或者底層系統(tǒng)支持的任何其他名稱分隔符來分隔其中的名稱。

Caused by: java.io.InvalidClassException: models.member.Member; local class incompatible: stream classdesc serialVersionUID = 8996579512119659486, local class serialVersionUID = -7513555048418418149

將本地的序列化的類中的版本號（serialVersionUID ）改成和遠程中一樣，在本地的序列化類里的private static final long serialVersionUID =  改成遠程的就行了，如果沒有的話就加上這句。

order by isTop desc

      在push之前有時候會不放心是不是忘記加某些文件，或者是不是多刪了個什么東西，這時候希望能夠看看上次commit都做了些什么。

一開始想到的是用git diff，但是git diff用于當前修改尚未commit的時候較為方便，一旦commit后，需要指定上次節(jié)點的名稱（一個hash值），不方便。這種時候用git log更合適，因為commit的內(nèi)容會以log來記錄。

下面記錄幾個常用的情境以及對應的命令。

僅僅想看最近誰有提交，以及提交的描述

對應命令 git log

顯示Sample

 

commit 6305aa81a265f9316b606d3564521c43f0d6c9a3
Author: XXX
Date:   Thu Nov 3 11:38:15 2011 +0800

    fill author information in the head of files and format some code

commit 8e8a4a96e134dab8f045937efee35bd710006946
Author: XXX
Date:   Thu Nov 3 04:05:34 2011 +0800

    user management is mostly complete

    details:
    add support for account disable/enable
    rewrite most related views to suit the above need
    provide two decorators for access control (see README)
    fixed many errors in Milestone 1

commit 2870cd564371d8ad043d0da426a5770d36412421
Author: XXX
Date:   Mon Oct 17 20:19:04 2011 -0400

    fix the bug of get_ori_url_from_shorturl().

commit b6cdd881a19ecaff838d5825c3a6b7058fdd498a
Author: XXX
Date:   Mon Oct 17 20:17:37 2011 -0400

    fix the bug of get_article_from_short_url.

僅僅想看最后一次的提交

對應命令參數(shù) -n 1

顯示Sample

commit 6305aa81a265f9316b606d3564521c43f0d6c9a3
Author: XXX
Date: Thu Nov 3 11:38:15 2011 +0800

fill author information in the head of files and format some code

想看到最近一次提交所有更改過的文件

對應命令 git log -n 1 --stat

顯示Sample

commit 6305aa81a265f9316b606d3564521c43f0d6c9a3
Author: XXX
Date:   Thu Nov 3 11:38:15 2011 +0800

    fill author information in the head of files and format some code

Site/accounts/decorators.py                        |    2 +-
Site/accounts/forms.py                             |    1 +
Site/accounts/models.py                            |    1 +
Site/accounts/readme                               |    3 ++-
Site/accounts/templates/account_activate.html      |    1 +
Site/accounts/templates/account_disabled.html      |    1 +
…

…

28 files changed, 37 insertions(+), 8 deletions(-)

想看到最近一次提交所有更改的細節(jié)

對應命令 git log -n 1 -p

顯示Sample

commit 6305aa81a265f9316b606d3564521c43f0d6c9a3
Author: XXX
Date:   Thu Nov 3 11:38:15 2011 +0800

    fill author information in the head of files and format some code

diff --git a/Site/accounts/decorators.py b/Site/accounts/decorators.py
index 22522bc..a6bb440 100755
--- a/Site/accounts/decorators.py
+++ b/Site/accounts/decorators.py
@@ -1,9 +1,9 @@
#!/usr/bin/env python
# -*- coding: utf-8 -*-
+# author: Rex Nov. 3, 2011
from functools import wraps
from django.core.urlresolvers import reverse
from django.http import HttpResponseRedirect
-from django.utils.decorators import available_attrs
from Site.accounts.models import UserProfile

def login_required(view_func):
diff --git a/Site/accounts/forms.py b/Site/accounts/forms.py
index 016710b..778d92a 100755
--- a/Site/accounts/forms.py
+++ b/Site/accounts/forms.py
@@ -1,5 +1,6 @@
#!/usr/bin/env python
# -*- coding: utf-8 -*-
+# author: Rex Nov. 3, 201

…

…

有了這幾條命令，基本上對于想看最近更改的情境就可以應付過去了。最后一條并不很常用，如果有visual的工具可能更直觀些。

      Onunload，onbeforeunload都是在刷新或關(guān)閉時調(diào)用，可以在<script>腳本中通過window.onunload 來指定或者在<body>里指定。區(qū)別在于onbeforeunload在onunload之前執(zhí)行，它還可以阻止onunload的執(zhí)行。

    Onbeforeunload也是在頁面刷新或關(guān)閉時調(diào)用，Onbeforeunload是正要去服務(wù)器讀取新的頁面時調(diào)用，此時還沒開始讀??；而 onunload則已經(jīng)從服務(wù)器上讀到了需要加載的新的頁面，在即將替換掉當前頁面時調(diào)用。Onunload是無法阻止頁面的更新和關(guān)閉的。而 Onbeforeunload 可以做到。曾經(jīng)做一個考試系統(tǒng)，涉及到防止用戶半途退出考試（有意或者無意），代碼如下：

這樣可以讓用戶確認是否要退出考場，其實BLOGJAVA在用戶編寫B(tài)LOG時，如果不保存而跳轉(zhuǎn)到其他頁面，也會有一個確認的提示（防止誤操作），也是用到Onbeforeunload。

   另外還可以用來在頁面關(guān)閉的時候關(guān)閉session，代碼如下(注：用window.screenLeft > 10000 來區(qū)分關(guān)閉和刷新操作)：

問題描述：firefox下js中動態(tài)組裝select時指定option的selected屬性的失效

錯誤 org.hibernate.HibernateException: ordinal parameter mismatch 。

我們都知道hibernate3可以調(diào)用存儲過程或函數(shù)，但是有一定的限制(具體可以查看hibernate官方手冊)。
據(jù)我分析這段代碼應該是用來分析字符串是否是調(diào)用存儲過程或函數(shù)的語句。
解決方法：
1.不要在表或列中，出現(xiàn)"call"字樣
2.用Criteria來代替hql語句

String和StringBuffer的區(qū)別，網(wǎng)上資料可以說是數(shù)不勝數(shù)，但是看到這篇文章，感覺里面做的小例子很有代表性，所以轉(zhuǎn)一下，并自己做了一點總結(jié)。

在java中有3個類來負責字符的操作。

1.Character 是進行單個字符操作的，

2.String 對一串字符進行操作。不可變類。

3.StringBuffer 也是對一串字符進行操作，但是可變類。

String:
是對象不是原始類型.
為不可變對象,一旦被創(chuàng)建,就不能修改它的值.
對于已經(jīng)存在的String對象的修改都是重新創(chuàng)建一個新的對象,然后把新的值保存進去.
String 是final類,即不能被繼承.

StringBuffer:
是一個可變對象,當對他進行修改的時候不會像String那樣重新建立對象
它只能通過構(gòu)造函數(shù)來建立,
StringBuffer sb = new StringBuffer();
note:不能通過付值符號對他進行付值.
sb = "welcome to here!";//error
對象被建立以后,在內(nèi)存中就會分配內(nèi)存空間,并初始保存一個null.向StringBuffer
中付值的時候可以通過它的append方法.
sb.append("hello");

字符串連接操作中StringBuffer的效率要比String高:

String str = new String("welcome to ");
str += "here";
的處理步驟實際上是通過建立一個StringBuffer,讓侯調(diào)用append(),最后
再將StringBuffer toSting();
這樣的話String的連接操作就比StringBuffer多出了一些附加操作,當然效率上要打折扣.

并且由于String 對象是不可變對象,每次操作Sting 都會重新建立新的對象來保存新的值.
這樣原來的對象就沒用了,就要被垃圾回收.這也是要影響性能的.

看看以下代碼：
將26個英文字母重復加了5000次，

  String tempstr = "abcdefghijklmnopqrstuvwxyz";
  int times = 5000;
  long lstart1 = System.currentTimeMillis();
  String str = "";
  for (int i = 0; i < times; i++) {
  str += tempstr;
  }
  long lend1 = System.currentTimeMillis();
  long time = (lend1 - lstart1);
  System.out.println(time);
可惜我的計算機不是超級計算機，得到的結(jié)果每次不一定一樣一般為 46687左右。
也就是46秒。
我們再看看以下代碼

  String tempstr = "abcdefghijklmnopqrstuvwxyz";
  int times = 5000;
  long lstart2 = System.currentTimeMillis();
  StringBuffer sb = new StringBuffer();
  for (int i = 0; i < times; i++) {
  sb.append(tempstr);
  }
  long lend2 = System.currentTimeMillis();
  long time2 = (lend2 - lstart2);
  System.out.println(time2);
得到的結(jié)果為 16 有時還是 0
所以結(jié)論很明顯，StringBuffer 的速度幾乎是String 上萬倍。當然這個數(shù)據(jù)不是很準確。因為循環(huán)的次數(shù)在100000次的時候，差異更大。不信你試試。

根據(jù)上面所說：

str += "here";
的處理步驟實際上是通過建立一個StringBuffer,讓侯調(diào)用append(),最后
再將StringBuffer toSting();

所以str += "here";可以等同于

StringBuffer sb = new StringBuffer(str);

sb.append("here");

str = sb.toString();

所以上面直接利用"+"來連接String的代碼可以基本等同于以下代碼

  String tempstr = "abcdefghijklmnopqrstuvwxyz";
  int times = 5000;
  long lstart2 = System.currentTimeMillis();
  String str = "";
  for (int i = 0; i < times; i++) {
  StringBuffer sb = new StringBuffer(str);
  sb.append(tempstr);
  str = sb.toString();
  }
  long lend2 = System.currentTimeMillis();
  long time2 = (lend2 - lstart2);
  System.out.println(time2);
平均執(zhí)行時間為46922左右，也就是46秒。

本文來自CSDN博客，轉(zhuǎn)載請標明出處：http://blog.csdn.net/yirentianran/archive/2008/09/03/2871417.aspx

StringBuffer維護了一個大小固定的字符串緩沖區(qū)，當字符串長度超過StringBuffer大小時會自動增加，主要使用Insert和append方法，對于運行期要進行字符串的組裝操作推薦使用，

  StringBuilder: jdk5以后有個和StringBuffer等價的StringBuider，區(qū)別在于StringBuffer是線程安全的，StringBuilder是單線程的，不提供同步，理論上效率更高。

  String是系統(tǒng)內(nèi)置類型，而且是final的，定義一個字符串會產(chǎn)生一個實例和一個對該實例地址的引用。

  如果在編譯期間定義的字符串，例如 :

  String a = "name";
  a += "is";
  a += "good";

  盡管這種方法是不被推薦的，但在編譯期，編譯器會對該代碼進行優(yōu)化，所以還是可以理解為:String a = "name is good";而如果在此時采用StringBuffer，反而會推遲到運行期才會被處理，相比之下，反而會比StringBuffer效率更高，靈活運 用。
String 字符串常量
StringBuffer 字符串變量（線程安全）
StringBuilder 字符串變量（非線程安全）
 簡要的說， String 類型和 StringBuffer 類型的主要性能區(qū)別其實在于 String 是不可變的對象, 因此在每次對 String 類型進行改變的時候其實都等同于生成了一個新的 String 對象，然后將指針指向新的 String 對象，所以經(jīng)常改變內(nèi)容的字符串最好不要用 String ，因為每次生成對象都會對系統(tǒng)性能產(chǎn)生影響，特別當內(nèi)存中無引用對象多了以后， JVM 的 GC 就會開始工作，那速度是一定會相當慢的。
 而如果是使用 StringBuffer 類則結(jié)果就不一樣了，每次結(jié)果都會對 StringBuffer 對象本身進行操作，而不是生成新的對象，再改變對象引用。所以在一般情況下我們推薦使用 StringBuffer ，特別是字符串對象經(jīng)常改變的情況下。而在某些特別情況下， String 對象的字符串拼接其實是被 JVM 解釋成了 StringBuffer 對象的拼接，所以這些時候 String 對象的速度并不會比 StringBuffer 對象慢，而特別是以下的字符串對象生成中， String 效率是遠要比 StringBuffer 快的：
 String S1 = “This is only a” + “ simple” + “ test”;
 StringBuffer Sb = new StringBuilder(“This is only a”).append(“ simple”).append(“ test”);
 你會很驚訝的發(fā)現(xiàn)，生成 String S1 對象的速度簡直太快了，而這個時候 StringBuffer 居然速度上根本一點都不占優(yōu)勢。其實這是 JVM 的一個把戲，在 JVM 眼里，這個
 String S1 = “This is only a” + “ simple” + “test”; 其實就是：
 String S1 = “This is only a simple test”; 所以當然不需要太多的時間了。但大家這里要注意的是，如果你的字符串是來自另外的 String 對象的話，速度就沒那么快了，譬如：
String S2 = “This is only a”;
String S3 = “ simple”;
String S4 = “ test”;
String S1 = S2 +S3 + S4;
這時候 JVM 會規(guī)規(guī)矩矩的按照原來的方式去做

在大部分情況下 StringBuffer > String
StringBuffer
Java.lang.StringBuffer線程安全的可變字符序列。一個類似于 String 的字符串緩沖區(qū)，但不能修改。雖然在任意時間點上它都包含某種特定的字符序列，但通過某些方法調(diào)用可以改變該序列的長度和內(nèi)容。
可將字符串緩沖區(qū)安全地用于多個線程?？梢栽诒匾獣r對這些方法進行同步，因此任意特定實例上的所有操作就好像是以串行順序發(fā)生的，該順序與所涉及的每個線程進行的方法調(diào)用順序一致。
StringBuffer 上的主要操作是 append 和 insert 方法，可重載這些方法，以接受任意類型的數(shù)據(jù)。每個方法都能有效地將給定的數(shù)據(jù)轉(zhuǎn)換成字符串，然后將該字符串的字符追加或插入到字符串緩沖區(qū)中。 append 方法始終將這些字符添加到緩沖區(qū)的末端；而 insert 方法則在指定的點添加字符。
例如，如果 z 引用一個當前內(nèi)容是“start”的字符串緩沖區(qū)對象，則此方法調(diào)用 z.append("le") 會使字符串緩沖區(qū)包含“startle”，而 z.insert(4, "le") 將更改字符串緩沖區(qū)，使之包含“starlet”。
在大部分情況下 StringBuilder > StringBuffer
java.lang.StringBuilde
java.lang.StringBuilder 一個可變的字符序列是5.0新增的。此類提供一個與 StringBuffer 兼容的 API，但不保證同步。該類被設(shè)計用作 StringBuffer 的一個簡易替換，用在字符串緩沖區(qū)被單個線程使用的時候（這種情況很普遍）。如果可能，建議優(yōu)先采用該類，因為在大多數(shù)實現(xiàn)中，它比 StringBuffer 要快。兩者的方法基本相同。
通過非官方試驗測試，StringBuilder和StringBuffer的測試總結(jié)如下：

1． 為了獲得更好的性能，在構(gòu)造 StirngBuffer 或 StirngBuilder 時應盡可能指定它的容量。當然，如果你操作的字符串長度不超過 16 個字符就不用了。

2． 相同情況下使用 StirngBuilder 相比使用 StringBuffer 僅能獲得 10%~15% 左右的性能提升，但卻要冒多線程不安全的風險。而在現(xiàn)實的模塊化編程中，負責某一模塊的程序員不一定能清晰地判斷該模塊是否會放入多線程的環(huán)境中運行，因 此：除非你能確定你的系統(tǒng)的瓶頸是在 StringBuffer 上，并且確定你的模塊不會運行在多線程模式下，否則還是用 StringBuffer 吧 J

3． 用好現(xiàn)有的類比引入新的類更重要。很多程序員在使用 StringBuffer 時是不指定其容量的（至少我見到的情況是這樣），如果這樣的習慣帶入 StringBuilder 的使用中，你將只能獲得 10 ％左右的性能提升（不要忘了，你可要冒多線程的風險噢）；但如果你使用指定容量的 StringBuffer ，你將馬上獲得 45% 左右的性能提升，甚至比不使用指定容量的 StirngBuilder 都快 30% 左右。

在原先的json數(shù)據(jù)中再新增數(shù)據(jù)

callFun.extend("bind",function(){...// 新的操作}) 

在向NFS上備份的時候，數(shù)據(jù)的流向是這樣的：MySQL Server端從數(shù)據(jù)文件中檢索出數(shù)據(jù)，然后分批將數(shù)據(jù)返回給mysqldump客戶端，然后mysqldump將數(shù)據(jù)寫入到NFS上。一般地，向NFS 上寫入數(shù)據(jù)的速度較之Server端檢索發(fā)送數(shù)據(jù)的速度要慢得多，這就會導致mysqldump無法及時的接受Server端發(fā)送過來的數(shù)據(jù)，Server端的數(shù)據(jù)就會積壓在內(nèi)存中等待發(fā)送，這個等待不是無限期的，當Server的等待時間超過net_write_timeout（默認是60秒）時它就失去了耐心，mysqldump的連接會被斷開，同時拋出錯誤Got error: 2013: Lost connection。

http://hi.baidu.com/ldtrain/blog/item/1c7f87be76c9020119d81f18.html