ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • iBATIS, Hibernate, and JPA: Which is right for you?
    개발 2019. 8. 8. 11:08

    이 기사에서 우리는 두 개의 가장 유명한 오랫동안 쓰인 오픈 소스 framework를 소개 하고 비교한다. Ibatis  hibernate. 우리는 또한 Java persistence API 에 대해서 검토해 보고, 각 솔루션을 소개하고, 게다가 broad application scenarios 의 강점과 약점을 포함한 각각의 솔루션 품질에 대해서도 검토해 볼 것이다. 그 후에 IBATIS Hibernate  JPA 를 기반으로 한 성능, 이식성, 복잡성, 데이터 모델이 변할 때의 적용성의 요소를 통해 비교해 볼 것이다. 만약 당신이 초보 자바프로그래머이고 persistence concepts 이 처음이라면 이 기사를 읽는 것은 이 주제와 가장 유명한 오픈 소스 persistence solutions의 가장 좋은 입문서가 될 수 있다. 만약 당신이 위의 세가지를 잘 알고 직관적인 비교를 원한다면, comparing persistence technologies 섹션을 찾아보세요

     

    Understanding persistence

    Persistence  application 수명이  한다고 하더라도 데이터의 안정 성을 지켜   있는 데이터의 속성을 말한다. 자바와 같은 객체 지향 언어는 객체를 만든 어플리케이션의 실행이 종료된 상태에의 persistence 접근을 보장한다.

    Persistence 달성하기 위해서는 여러 가지 방법이 있다. 전통적인 방법의 문제점은 플랫 파일에 필요한 정보를 저장하는 파일시스템을 사용하는 것이다. 이는 대용량 데이터에 대한 관리가어렵다. 왜냐하면 데이터는 다른 파일 등에 분산되기 때문이다. 데이터를 일관되게 유지하는 또한 flat file systems 에서는 중요한 이슈이다. 왜냐하면 같은 정보 또한 다시 여러 개의 파일로복사   있기 때문이다. Flat files 에서 데이터를 찾는 것은 시간이 많이 걸립니다. 특히 정렬이안되어있는 상태에서는 더욱 오래 걸린다. 또한 파일 시스템은 제한적으로 동시적인 접속을 지원 하기 때문에 데이터에 대한 완전성을 보장하기는 힘들다. 이러한 이유로 파일 시스템은persistence 요구할 때에는 최적의 데이터 스토리지 솔루션에서는 고려대상이 아니다.

    요즘 대부분의 공통된 접근법은 데이터 베이스를 사용하여 많은 양의 데이터를 위한 데이터 저장소를 제공하고 있다. 이에는 많은 종류의 데이터 베이스가 있다. : 관계형, 계층형, 네트워크형, 객체형  이러한 database management system  특성을 따른 형태의 데이터 베이스는. Persistence 편의를 제공하는  뿐만 아니라. 정보에 대한 지속성을 관리  주기도 한다. 관계형 데이터 베이스들은 가장 많이 쓰이는 타입이다. 관계형 데이터베이스에서의 데이터는 관련table 집합에 의해서 설계 된다.

    Enterprise 어플리케이션의 출현은 다층 구조를 대중화 시켰다. 이는 presentation, business 데이터베이스 관련 코드들을 다른 계층으로 분리하여 관리함으로써 유지보수성을 향상 시켰다.

    Business logic  database code 관련 층은 persistence 층으로 분리되는데 이는 기본 데이터 베이스 종류에 관계 없이 어플리케이션을 유지하는 층으로 이로 인하여 개발자는 데이터의 지속성을 관리해야  필요가 없어지게 해줍니다. The persistence 층은 데이터가 데이터를 저장하고관계형 데이터베이스에서 검색하는 방법을 캡슐화 하기도 합니다.

    관계형 데이터 베이스에서 자바 어플리케이션은 전통적으로 JDBC API 사용하여 데이터를 지속 해왔다. JDBC API SQL statements  사용하여 생성하고, 읽고, 업데이트 하고 삭제 하는연산을 실행시킨다. JDBC code 자바 클래스에 내장되어있다.  그것은 다른 말로 밀착 결합된business logic이라는 것이다. 또한  code 표준화 되지 않은 database code  SQL 매우의존 합니다. 이는 하나의 데이터 베이스에서 다른 데이터 베이스로 옮기는 것을 매우 어렵게 만드는 요인 입니다.

    관계형 데이터베이스 기술은 데이터와의 관계를 강조하는 반면, 자바에 사용되는 객체 지향 패러다임은 데이터 자체에 집중하지만. 작업 중인 상태의 데이터에 대해서는   기술모두 함께작용 해야 하는 경우 이해 관계에 의한 충돌이 있을  있습니다. 또한 객체 지향 프로그래밍 컨셉의 상속성과, 다형성과 연계성은 데이터 베이스에 의해 해결되지 않습니다. 이러한 잘못된 조합에서 오는 다른 문제점은 java 응용 프로그램에 정의  사용자 정의 데이터 유형이 관계형 데이터베이스에 매핑 되면, 관계형 데이터 베이스에서는 똑같은 종류의 타입은 지원하지 않을 문제가 발생됩니다.

     

    Object-relational mapping

    Object-relational mapping(ORM) object-relational impedance mismatch 라며 불리 불리며 떠오르고 있는 솔루션이다. ORM 관계형 데이터베이스에 있는 투명한 테이블에서 어플리케이션객체를 유지하는 기술입니다. ORM 데이터베이스 구조를 유저로부터 숨기고 가상 데이터 베이스처럼 동작합니다. ORM CRUD 완벽하게 수행하는 기능들을 제공하며 객체지향 쿼리를 지향합니다. 또한 ORM  metadata mapping  지원하며 어플리케이션의 transaction management  도와줍니다.

    밑에 있는 그림은 ORM 어떻게 동작하는지 알려주는데 도움이  것입니다. 데이터베이스에서 지속되어야 하는 간단한 car 객체를   있습니다.  도메인 모델의 자동차 객체는 데이터 모델의 자동차 테이블을 표현합니다. 자동차 객체의 속성은 자동차 테이블의행에서 비롯된 객체 입니다. 다음 그림 1 보면 car 클래스와 car테이블의 direct mapping 이라고 합니다.

     

    Figure 1

    현재 Hibernate, iBATIS SQL Map, Java Ultra-Lite Persistence  같은 많은 종류의 open source ORM tools 툴이 있습니다.  많은 툴들은 대부분 JAVA application 층과 Data base  사이에 추상적인 층을 제공 하는 persistence frameworks 입니다. Persistence framework  데이터 베이스에 유지해야 하는 데이터에 대한 어플리케이션 도메인의 개체를 매핑 합니다. 매핑은 XML files 이나 metadata annotations  이용해 정의   있습니다. (자바 버전 1.5 이후에 소개된 기능입니다.) persistence frameworks database 관련 code  어플리케이션 관련 코드를 분리하는 데에 초점을 맞췄습니다.(이것을business logic이라고 합니다.) 이로 인하여 어플리케이션의 유연성을 증가 시킬  있습니다. persistence frameworks persistence logic  위한 wrapper  제공하여 간단하게개발을 진행할  있게 해줍니다.

    이러한 persistence  대한 기본적인 소개로 우리는 iBATIS  Hibernate  같은 두가지의 가장 유명한 오픈소스 persistence frameworks 논의   있게 되었습니다. 또한 우리는 pava persistence API  소개  것이고 다양한 응용 프로그램 시나리오의  가지솔루션의 강점과 약점에 대해서 설명하겠습니다.

     

    iBATIS: Using SQL directly

    Object-relational mapping (ORM) hood 아래에 JDBC 또는 SQL 코드를 생성하는 직접매핑을 사용합니다. 그러나, 일부 응용 프로그램 시나리오의 경우 당신은 SQL 쿼리를 통해 보다 직접적인 컨트롤이 필요합니다. 업데이트 쿼리의 시리즈를 포함하는 응용 프로그램을 작성하는 경우, ORM 의해 생성된 SQL 의존하는 것보다 자신의 SQL 쿼리를 직접작성하는 것이  효과적입니다. 또한, 객체 모델과 데이터 모델 사이에 불일치가 있을 경우 ORM 사용할  없다. 우리가 언급했듯이, 이전에는 데이터베이스 코드를 많이 도입하고, 응용 프로그램을 강력하게 유지 관리하기 위한 일반적인 솔루션으로 JDBC 코드가소개 되어왔다. 응용 프로그램 코드에서 persistence 레이어는 응용 프로그램과 데이터베이스를 분리하는  필요합니다.

    iBATIS Data Mapper framework  이러한 문제를 해결하기 위한 솔루션입니다. iBATIS  SQL  사용 하는데 좋지만, JDBC 복잡성은 줄여 주는 persistence framework 입니다. 다른 대부분의 persistence framworks 들과는 다르게 iBATIS  SQL  직접적으로사용   있게 도와주며 SQL 사용하는데 framework 의해 override 되는  방지해주어 안정성을 보장 합니다.

    data-access code 빌드할  사용   있는 간단한 맵핑과 API layer 제공 하는 처럼 이러한 간단함이 iBATIS 가장  장점입니다.  framework 에서 데이터 모델과객체 모델은 정확하게 서로 맵핑  필요는 없습니다. 왜냐하면 iBATIS 데이터베이스의테이블 도메인을 맵핑 하는 객체와 같은 metadata mapper  사용 하기 보다 stored procedures  맵핑하는 객체나 SQL statements 혹은 XML descriptor  통한ResultSetS  사용하기 때문이다. 그러므로 iBATIS  데이터 모델과 객체 모델을 독립시킬  있습니다.

     

    iBATIS in brief

    iBATIS 프로젝트는 클린턴이 시작하였으면 2001년에 출시되었다.  퍼시스턴스 프레임워크는 최초에 자바를 위해 설계되었고 .Net Ruby 포함한 다른 플랫폼에 대한 지원을확장해나가고 잇다

     

    How iBATIS works

    iBATIS abstraction layer 도입해서 데이터베이스에서의 입력과 출력을 매핑하여 데이터베이스  애플리케이션간의 느슨한 결합을   있습니다. 맵핑은 SQL 쿼리를 포함하는 XML 파일을 사용하여 수행됩니다. 느슨한 결합은 애플리케이션과 데이터베이스설계가 일치하지 않는 시스템에서도 매핑작업이 원할하도록 해준다. 또한 수차례 바뀐 데이터베이스와 레거시 데이터베이스를 다루는데도 도움이 된다

    iBATIS framework  주로 아래의  xml 파일을 사용하여 기술한다.

    ·         SQLMapConfig.xml

    ·         SQLMap.xml

     

    SQLMapConfig.xml

    SQLMapConfig.xml 데이터 소스와 관련한 설정과 같은 상세 설정에 대한 모든것들이포함되어 있으며, 트랜잭션 관리에 대한 정보도 포함될  있다.  파일은 여러개 존재할 있는 SQLMap.xml파일을 구분지어 주고 로딩시키는 역할을 한다.

     

    데이터베이스의 EMPLOYEE 매핑되는 Employee 있다고 가정해보자. 클래스의 프로퍼티들로는 테이블 칼럼 이름과 유사한 emp_id, emp_firstname, emp_lastname 있다. Employee 대한 클래스 다이어그램은 Figure 2 잇다. ( 클래스는  문서에서 논의할 상이한 퍼시스턴스 기술을 설명하는데 사용될 것이다)

     

    Figure 2

    Employee클래스를 위한 SQLMapConfig.xml 파일은 Listing 1처럼 설정된다

     

    Listing 1. SQLMapConfig.xml file for Employee

     

    <sqlMapConfig>

      <transactionManager type="JDBC" commitRequired="false">

        <dataSource type="EMPLOYEE">

         <property name="JDBC.Driver"           value="com.mysql.jdbc.Driver"/>

          <property name="JDBC.ConnectionURL" value="jdbc:mysql://localhost:3306/ibatis"/>

          <property name="JDBC.Username" value="root"/>

          <property name="JDBC.Password" value=""/>

        </dataSource>

      </transactionManager>

     <!-- List the SQL Map XML files. They can be loaded from the classpath, as they are here (com.mydomain.data...) -->

      <sqlMap resource="com/mydomain/data/Employee.xml"/>

     </sqlMapConfig>

     

     

    SQLMapConfig.xml 데이터 소스가 이런 SQL맵을 사용하게 하기 위한 설정을 위해transactionManager 태그를 사용한다. 데이터소스의 타입을 지정하거나,   자세히는드라이버, 데이터베이스URL, 사용자 이름 정보를 포함한다. sqlMap 태그에는 로딩될  SQLMap.xml파일의 위치가 있다.

     

    SQLMap.xml

    다른 XML파일은 SQLMap.xml ,  이름처럼 테이블간에 관계에 대한 정보를 가진다.  파일은 하나의 애플리케이션에서 여러개를 가질  있다.  파일은 SQL 문장들과 매핑되는 도메인 객체가 있는 것이 위치한다.  descriptor 입력으로 쓰일 문장과 SQL ResultSets 매핑되는 결과에 대한 내용을 표기한다.  파일은 쿼리를 포함하기도 한다. 따라서 쿼리를 바꾸려면 애플리케이션의 자바 코드를 바꾸는 것이 아니라 XML 바꾸어야 한다. 매핑은 데이터베이스와 상호작용할 실제 SQL문장을 사용하여 이루어진다. 이렇게 SQL 사용하는 것은 개발자에게 매우  융통성을 부여하며  SQL프로그래밍 경험을가진 누구에게나 iBATIS 쉽게 이해할  있게 해준다.

    EMPLOYEE테이블에 대한 CRUD연산을 수행하는 SQL문을 정의한 SQLMap.xml파일이아래 Listing 2 있다.

     

    Listing 2. SQLMap.xml for operations on EMPLOYEE

    Listing 2에서 typeAlias 태그는 타입에 대한 별칭으로 사용되어서 매번 경로까지 포함한전체 클래스명을 타이핑하지 않아도 되도록 해준다.  태그는 쿼리로부터 반환되는 컬럼과 Employee클래스로 표현되는 클래스의 프로퍼티에 대한 매핑 정보를 가지는resultMap 태그를 포함한다.  resultMap태크에 이어 쿼리들이 정의된다. SQLMap.xml 여러개의 쿼리들을 포함한다. select, insert, update, delete 문장들은 각각의 태그안에쓰여진다. 모든 문장은 id 어트리뷰트를 사용하여 이름이 지어진다.

     

    Loading the descriptor files to your Java application

     

    XML파일들간에 매핑작업과 전체적인 설정이 완료되면 SQLMapConfig.xml 자바 애플리케이션에서 가져와 사용해야 한다. 첫단계는 앞서 작성했던 SQLMap.xml 설정파일을로딩하는 것이다. 이를 위해 Listing 3. 있는 iBATIS 프레임워크에 포함되어 있는com.ibatis.common.resources.Resources 클래스를 사용할 것이다.

     

    Listing 3. Loading SQLMap.xml

     

    private static SqlMapClient sqlMapper;

    ...

     try {

          Reader reader = Resources.getResourceAsReader("com/mydomain/data/SqlMapConfig.xml");

          sqlMapper = SqlMapClientBuilder.buildSqlMapClient(reader);

          reader.close();

        } catch (IOException e) {

          // Fail fast.

          throw new RuntimeException("Something bad happened while building the SqlMapClient instance." + e, e);

        }

      }

    SqlMapClient클래스는 SQLMaps 함께 사용된다. 이는 select, insert, update등과 같은문장들에 해당하는 액션들을 수행한다. SqlMapClient객체는 Thread safe하기때문에 한개의 객체만 사용해도 충분하다. 따라서 static 멤버로 선언하는 것이 적절하겠다.  객체는하나의 SQLMapConfig.xml파일로부터 설정 정보를 읽어와 생성된다. iBATIS프래임워크는 SQLMapConfig.xml파일을 읽기 위한 Resources.getResourceAsReader() 유틸리티를제공한다. 따라서 SQLMap클래스의 인스턴스를 사용하여 데이터베이스로부터 객체에 접근할  있다.(이번 경우에는 Employee객체)

     

    EMPLOYEE테이블에 있는 연산을 호출하기 위해서 여러종류의 메소드가 있지만 그중에서도 queryForList(), queryForObject(), insert(), update(), queryForMap() 같은 SQLMap에서 제공하는 메소드들이 제공된다.  Listing4 있는 queryForList()메소드는 Employee객체들의 리스트를 반환한다.

     

    Listing 4. queryForList()

    sqlMapper.queryForList("selectAllEmps");

    쿼리의 결과로 한개의 로우를 가져오고자 할때는 queryForObject() 사용하면 된다. 두가지 메소드 모두 파라미터로 쿼리문의 이름을 받는다.

    이와 유사하게 Listing 5처럼  insert, update, delete연산을 수해할  있는 메소드들이 있다.  메소드들은 SQLMap.xml파일에 선언된 쿼리분의 이름과 파라미터로 Employee객체를 넘겨받는다.

    Listing 5. Insert, update, and delete operations

    sqlMapper.insert("insertEmp", emp);

    sqlMapper.update("updateEmp", emp);

    sqlMapper.delete("deleteEmp", id);

    iBATIS에서는 이런 방식으로  SQL문장을 직접적으로 사용하여 자바객체를 저장하게 된다.

     

    언제 iBATIS 사용하는가

     

    iBATIS SQL 대한 모든 컨트롤을 하고자 할때 매우 적합하다. SQL쿼리들이 매우 최적화되어 있을 때에도 유용하다. iBATIS 애플리케이션과 데이터베이스간의 설계에대한 모든 조작을 하고자 할때는 적합하지 않다.  이유는 애플리케이션과 데이터베이스간에 서로  구조화되도록 설정이 바뀌어야 하기 때문이다. 이러한 경우에 객체관계(object-relational)애플리케이션을 개발할  있으며 다른 ORM툴을 사용하는 것이  올바른 선택일 것이다. iBATIS 상대적으로  SQL중심적이기때문에, ORM툴들이 생성해내는 SQL 반해 iBATIS SQL 직접적으로 사용하게 된다. iBATIS 관계 데이터베이스가 아닌 데이터베이스들을 사용할 때에도 적절치 않다. 그러한 데이터베이스들은 트랜잭션이나 iBATIS 사용하는 주요 기능들을 제공하지 않기 때문이다.

     

     

    Hibernate:

     

    Hibernate 오픈소스로 경량의 객체관계 매핑 솔루션이다. Hibernate 주요 특징은 객체 기반의 모델링을 지원함으로서 퍼시스턴스에 대하여 투명한 체계를 제공한다는 점이다. 데이터페이스와 애플리케이션간의 매핑을 위해 XML 이용하고 매우 정제되어 이는객체를 지원한다. 현재 Hibernate 버전은 3.x이며 향후 Java annotation 지원하고 EJB스팩을 모두 지원해나갈 예정이다.

    Hibernate Hibernate Query Language 혹은 HQL이라 불리는 매우 강력한 쿼리 언어를포함하고 있다. HQL SQL 매우 비슷하며 추가적인 컨벤션을 정의할 수도 있다. HQL 완전히 객체 지향적이며 이로써 상속, 다형성, 관계등의 객체지향의 강점을 누릴수 있다. HQL쿼리는 자바 클래스와 프로퍼티의 이름을 제외하고는 대소문자를 가린다. HQL쿼리 결과로 객체를 반환하며 프로그래머의에 생성되고 직접적으로 접근되어질  있다. HQL 페이지네이션이나 동적 프로파일링같은 SQL 지원하지 않는 향상된 기능을 제공한다. HQL 여러 테이블을 작업할때에 명시적인 join 요구하지 않는다

     

    Hibernate in brief

     Hibernate Gavin King 주축으로  팀에 의해 개발되었따. Hibernate 개발은 2001년에 시작되었고  팀은 현재 JBoss 유지보수하고 있는 팀으로 JBoss 후발로 만들어진 팀이다. Hibernate Java 만들어졌으며 2005년에는 NHibernate라고 소개되었던.Net버전을 출시하였다

     

     Hibernate 필요로 하는가?

     

    객체 관계 매핑을 위해 전통적으로 사용되어 오던 Entity beans 이해하기 어려우며 유지관리가 어렵다. Hibernate 특정 클래스에 매핑되어야 하는 데이터베이스의 테이블에 대한 관계 정의가 되어 있는 XML 파일의 메타데이터로 객체관계 매핑을 간단하게 수행시키신다. 다른 persistence 프레임워크는 객체관계의 매핑을 위해 애플리케이션 클래스를 수정해야할지 미로즤만 Hibernate에서는 그렇게  필요가 없다.

     

    Hibernate 사용하면 데이터베이스가 변경되더라도 SQL스크립트를 변경하는등의 작업을 피할  있다. 애플리케이션에서 사용되는 데이터베이스를 변경시키고자 한다면 설정파일의 dialect 프로퍼티를 수정함으로서 쉽게 처리할  있다. Hibernate  기존의 상업용 ORM 프레임워크로부터는 제공되지 못했던 SQL 모든 기능을 완벽하게 지원한다. Hibernate MySQL, Oracle, Sybase, Derby, PostgreSQL 포함한 많은 데이터베이스를 지원하며 POJO기반의 모델과도 원활하게 동작한다.

     

    Hibernate 선택된 데이터베이스에 기반하여 JDBC코드를 생성하므로써 JDBC코드를쓰면서 사용하는 문제로부터 해방시켜준다. 또한 커넥션 풀도 지원해준다. Hibernate에서사용되는  API 매우 간단하고 배우기 쉽다. 개발자는 SQL 대한 기초 지식만 있떠라도Hibernate 사용할  있으며 SQL쿼리를 집합을 쉽게 사용할  있게 해준다.

     

    Hibernate 아키텍쳐

     

    내부적으로 Hibernate 다른 애플리케이션과의 통함을 위한 JTA(Java Transaction API) JNDI 적용하기 위한 데이터베이스의 추상화 계정을 제공하는 JDBC 사용한다. 데이터베이스와의 상호작용에 필요한 Hibernate 연결 정보는 JDBC connection pool의해 제공된다.

     

    Hibernate 아키텍쳐는 두개의 주요 인터페이스로 구성되는데 Session Transaction그것이다. 이는 애플리케이션의 퍼시스턴스 계층에 있는  Query 인터페이스와 함께 사용된다. 애플리케이션의 비즈니스 계층에 정의된 클래스들은 특정 JDBC API들을 사용하는데이터베이스 계층과의 상호작용을 하기 위한 Hibernate 퍼스스턴스 계층과의 독립적인메타데이터를 통하여 상호작용한다. 더하여 Hibernate Configureation클래스라는 설정을 위한 인터페이스를 사용한다. Hibernate callback 인터페이스를 사용하게끔 하며 몇몇 추가적인 인터페이스는 기능적인 매핑의 확장을 위해 사용된다. Hibernate 전체적인아키텍쳐는 Figure3에서   있다.

     

    Hibernate architecture: The big picture

     

    Figure 3. Hibernate architecture: The big picture

     

    Hibernate 일부인 주요 프로그래밍 인터페이스는 다음과 같다

    org.hibernate.SessionFactory  session 인터페이스를 얻는데 사용되며 connection pool 메커니즘과 유사하게 보여질  있다. 모든 애플리케이션 내의 쓰레드가 하나의SessionFactory 사용하기 때문에 thread safe하다(Hibernate 하나의 데이터베이스를사용하는 한은.).  인터페이스는 설정 파일을 통해서 어떤 파일들이 로딩될지 결정된다. 

    org.hibernate.Session 애플리케이션과 데이터베이스간의 상호작용을 결정하기 위한하나의 쓰레드를 제공한다. 이는 single connection 유사하며 매우 경량이긴 하나thread safe하지 않다.

     

    org.hibernate.Transaction 애플리케이션에서의 원자적인 하나의 작업단위를 결정하는하나의 쓰레드 객체를 제공한다. 이는 기본적으로 JDBC, JTA, CORBA 트랜잭션에 기초한다.

     

    org.hibernate.Query HQL이나 데이터베이스에 있는  SQL 같은 쿼리를 수행하는데쓰인다. Query인스턴스는 가벼우며,  쿼리가 생성된 세션 밖에서는 사용할  없다는것에 주의해야 한다.

     

     

    Hibernate 설정

     

    Hibernate 설정은 hibernate.cfg.xml이라는 XML파일을 통해   있다.  설정 파일은특정 관계 데이터베이스로의 연결을 하기 위한 정보가 들어 있다. 설정 파일은 참조해야할 매핑파일을 알고 있어야 한다. 런타임에서 Hibernate 매핑파일을 읽고 데이터베이스의 테이블에 대응하는 동적 자바 클래스를 빌드하는데  매핑 파일을 사용한다. 예제 설정 파일은 Listing 6에서   있다.

     

    Listing 6. hibernate.cfg.xml

     

     

    <hibernate-configuration>

       <session-factory>

        <!-- local connection properties -->

         <property name="hibernate.connection.url">

            jdbc:mysql://localhost/hibernateDemo

         </property>

         <property name="hibernate.connection.driver_class">

            com.mysql.jdbc.Driver

         </property>

         <property  name="hibernate.connection.username">

    root

     </property>

         <property name="hibernate.connection.password">

    infosys

     </property>

         <!-- dialect for MySQL -->

         <property name="dialect">

            org.hibernate.dialect.MySQLDialect

         </property>

         <property name="hibernate.show_sql">false</property>

         <property name="hibernate.transaction.factory_class">

            org.hibernate.transaction.JDBCTransactionFactory

         </property>

         <mapping resource="Employee.hbm.xml" />

      </session-factory>

    </hibernate-configuration>

    '개발' 카테고리의 다른 글

    Spark 성능 튜닝 ( inferSchema )  (0) 2020.04.20
    python UDF 성능 개선 작업  (0) 2019.08.11
Designed by Tistory.