きぬろぐ

hibernateを使ってアプリを書いているのですが、主キーの自動採番にアプリで実装するのが面倒くさかったので(かといってDBでシーケンスを使うのもいや)hibernateのgenerator機能を使ってみました。

書き方は簡単。generatorクラスには”uuid”を指定して、hibernateがランダム生成するようにしました。昔はuuid.stringやuuid.hexという定義名だったらしいですが、hibernate 3.0系からuuid.stringの廃止、及びuuid.hex -> uuidに名称変更があった模様です。

uuidの特徴は以下

• 128ビットのUUIDアルゴリズムを利用し、長さが32の文字列IDを生成
• Hibernateによって自動的生成されるので、id値セットが不要

xmlの書き方は以下

<hibernate-mapping>
	<class name="net.kinusati.hibernate.test" table="testtable" catalog="testdb">
		<id name="primaryKey" type="string">
			<column name="PRIMARY_KEY" length="32" />
			<generator class="uuid" />
		</id>
	</class>
</hibernate-mapping>

実際生成された値は”297eea25258866420125886932070006″という文字列でした。

注意点としては、uuidを利用する場合は32バイトのカラム長が必要であること。最初VARCHAR(20)にしていたので、原因判明まで時間がかかりました・・・

ちなみにuuid.stringと指定した場合、以下の例外が出ます・・

org.hibernate.MappingException: could not instantiate id generator
	at org.hibernate.id.IdentifierGeneratorFactory.create(IdentifierGeneratorFactory.java:98)
	at org.hibernate.mapping.SimpleValue.createIdentifierGenerator(SimpleValue.java:152)
	at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:192)
	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1294)
	at org.hibernate.console.ConsoleConfiguration$3.execute(ConsoleConfiguration.java:492)
	at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:64)
	at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:94)
	at org.hibernate.console.ConsoleConfiguration.buildSessionFactory(ConsoleConfiguration.java:487)
	at org.hibernate.eclipse.console.workbench.LazySessionFactoryAdapter.getChildren(LazySessionFactoryAdapter.java:43)
	at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:99)
	at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:105)
	at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:234)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Caused by: org.hibernate.MappingException: could not interpret id generator strategy: uuid.string
	at org.hibernate.id.IdentifierGeneratorFactory.getIdentifierGeneratorClass(IdentifierGeneratorFactory.java:109)
	at org.hibernate.id.IdentifierGeneratorFactory.create(IdentifierGeneratorFactory.java:92)
	... 12 more
!SUBENTRY 2 org.hibernate.eclipse.console 4 150 2009-12-04 08:06:18.760
!MESSAGE org.hibernate.MappingException: could not interpret id generator strategy: uuid.string
!STACK 0
org.hibernate.MappingException: could not interpret id generator strategy: uuid.string
	at org.hibernate.id.IdentifierGeneratorFactory.getIdentifierGeneratorClass(IdentifierGeneratorFactory.java:109)
	at org.hibernate.id.IdentifierGeneratorFactory.create(IdentifierGeneratorFactory.java:92)
	at org.hibernate.mapping.SimpleValue.createIdentifierGenerator(SimpleValue.java:152)
	at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:192)
	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1294)
	at org.hibernate.console.ConsoleConfiguration$3.execute(ConsoleConfiguration.java:492)
	at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:64)
	at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:94)
	at org.hibernate.console.ConsoleConfiguration.buildSessionFactory(ConsoleConfiguration.java:487)
	at org.hibernate.eclipse.console.workbench.LazySessionFactoryAdapter.getChildren(LazySessionFactoryAdapter.java:43)
	at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:99)
	at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:105)
	at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:234)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

コメントする

Javaについてあまり詳しくなかったので、フレームワークと言語勉強をかねてStruts2 + hibernateでお勉強用Webアプリを制作していますが、なれない言語のため正直手こずっています(C/Perlの方が簡単・・)

でJavaといえば気になるのがスレッドセーフ(thread safe)。他言語でのスレッドセーフの作り方はわかるので、共用変数にステータスを持たせる等を行わなければスレッドセーフになることはわかるのですが、Struts2のサンプルプログラムを見ていて疑問に思ったことが。

import com.opensymphony.xwork2.ActionSupport;

public class indexAction extends ActionSupport {

    public String execute() throws Exception {
        return "success";
    }

    public String message;

    public String hello() throws Exception {
        message = “いえいえこちらこそこんにちは。”;
        return "hello";
    }
}

上記はatmarkitの記事で＠いう間にWebアプリを作れる「Struts 2」入門から抜き出した物ですが、ActionSupportのサブクラスにインスタンス変数を持たせた上、インスタンス変数にメッセージを代入した物を、JSPにはき出すようにしています。

<%@ page language="java" contentType="text/html; charset=UTF-8"
 pageEncoding="UTF-8"%>
 <%@ taglib prefix="s" uri="/struts-tags" %>
 <html>
 <body>
 <s:property value=”%{message}”/>
 </body>
 </html>

ふと思ったのが、そういえばStruts1系だとActionサブクラスは一つだけインスタンス化されるという記事。

• http://www.itmedia.co.jp/enterprise/0310/06/epn03_4.html
• http://rutake.ddo.jp/blog/techmemo/2007/07/strutsaction.html

atmarkit記事掲載のstruts2のサンプルだと、スレッドセーフではないのでは?と思っていたら、以下の記事が。

Struts 1.x Vs Struts 2.x

• Struts 1.x : Actionサブクラスはsingletonだから、スレッドセーフ or synchronizedにしないとだめ。Actionサブクラスにインスタンス変数を持たせてリクエスト毎の状態やメッセージを管理してはいけないということですね。
• Struts 2.x : ActionSupportサブクラスはHTTPリクエスト毎に生成されるため、スレッドセーフ問題は発生しない。ActionSupportサブクラスにインスタンス変数を持たせて、リクエスト毎のメッセージを代入しても、問題なくスレッドセーフです

struts 1.x系と違ってstruts 2.x系のサンプルがActionSupportサブクラスにインスタンス変数を持たせた上で、それをJSPに出力する物しか見つけられなかったのでどきどきしましたが、問題なしということですね。ほっとしました。

コメントする