53 lines
5.9 KiB
HTML
53 lines
5.9 KiB
HTML
<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE html><html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" xmlns:m="http://www.w3.org/1998/Math/MathML" xmlns:pls="http://www.w3.org/2005/01/pronunciation-lexicon" xmlns:ssml="http://www.w3.org/2001/10/synthesis" xmlns:svg="http://www.w3.org/2000/svg"><head><title>Appendix B. Meta-Data Schema</title><link rel="stylesheet" type="text/css" href="docbook-epub.css"/><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"/><link rel="prev" href="apas02.xhtml" title="Item Writers"/><link rel="next" href="apbs02.xhtml" title="BATCH_JOB_INSTANCE"/></head><body><header/><section class="appendix" title="Appendix B. Meta-Data Schema" epub:type="appendix" id="metaDataSchema"><div class="titlepage"><div><div><h1 class="title">Appendix B. Meta-Data Schema</h1></div></div></div><section class="section" title="Overview" epub:type="division" id="metaDataSchemaOverview"><div class="titlepage"><div><div><h2 class="title" style="clear: both">Overview</h2></div></div></div><p>The Spring Batch Meta-Data tables very closely match the Domain
|
||
objects that represent them in Java. For example,
|
||
<code class="classname">JobInstance</code>, <code class="classname">JobExecution</code>,
|
||
<code class="classname">JobParameters</code>, and
|
||
<code class="classname">StepExecution</code> map to BATCH_JOB_INSTANCE,
|
||
BATCH_JOB_EXECUTION, BATCH_JOB_EXECUTION_PARAMS, and BATCH_STEP_EXECUTION,
|
||
respectively. <code class="classname">ExecutionContext</code> maps to both
|
||
BATCH_JOB_EXECUTION_CONTEXT and BATCH_STEP_EXECUTION_CONTEXT. The
|
||
<code class="classname">JobRepository</code> is responsible for saving and storing
|
||
each Java object into its correct table. The following appendix describes
|
||
the meta-data tables in detail, along with many of the design decisions
|
||
that were made when creating them. When viewing the various table creation
|
||
statements below, it is important to realize that the data types used are
|
||
as generic as possible. Spring Batch provides many schemas as examples,
|
||
which all have varying data types due to variations in individual database
|
||
vendors' handling of data types. Below is an ERD model of all 6 tables and
|
||
their relationships to one another:</p><div style="text-align: center; " class="mediaobject"><img style="text-align: middle; " src="images/meta-data-erd.png"/></div><section class="section" title="Example DDL Scripts" epub:type="division" id="exampleDDLScripts"><div class="titlepage"><div><div><h3 class="title">Example DDL Scripts</h3></div></div></div><p>The Spring Batch Core JAR file contains example
|
||
scripts to create the relational tables for a number of database
|
||
platforms (which are in turn auto-detected by the job repository factory
|
||
bean or namespace equivalent). These scripts can be used as is, or
|
||
modified with additional indexes and constraints as desired. The file
|
||
names are in the form <code class="literal">schema-*.sql</code>, where "*" is the
|
||
short name of the target database platform. The scripts are in
|
||
the package <code class="literal">org.springframework.batch.core</code>.</p></section><section class="section" title="Version" epub:type="division" id="metaDataVersion"><div class="titlepage"><div><div><h3 class="title">Version</h3></div></div></div><p>Many of the database tables discussed in this appendix contain a
|
||
version column. This column is important because Spring Batch employs an
|
||
optimistic locking strategy when dealing with updates to the database.
|
||
This means that each time a record is 'touched' (updated) the value in
|
||
the version column is incremented by one. When the repository goes back
|
||
to try and save the value, if the version number has change it will
|
||
throw <code class="classname">OptimisticLockingFailureException</code>,
|
||
indicating there has been an error with concurrent access. This check is
|
||
necessary since, even though different batch jobs may be running in
|
||
different machines, they are all using the same database tables.</p></section><section class="section" title="Identity" epub:type="division" id="metaDataIdentity"><div class="titlepage"><div><div><h3 class="title">Identity</h3></div></div></div><p>BATCH_JOB_INSTANCE, BATCH_JOB_EXECUTION, and BATCH_STEP_EXECUTION
|
||
each contain columns ending in _ID. These fields act as primary keys for
|
||
their respective tables. However, they are not database generated keys,
|
||
but rather they are generated by separate sequences. This is necessary
|
||
because after inserting one of the domain objects into the database, the
|
||
key it is given needs to be set on the actual object so that they can be
|
||
uniquely identified in Java. Newer database drivers (Jdbc 3.0 and up)
|
||
support this feature with database generated keys, but rather than
|
||
requiring it, sequences were used. Each variation of the schema will
|
||
contain some form of the following:</p><pre class="programlisting">CREATE SEQUENCE BATCH_STEP_EXECUTION_SEQ;
|
||
CREATE SEQUENCE BATCH_JOB_EXECUTION_SEQ;
|
||
CREATE SEQUENCE BATCH_JOB_SEQ;</pre><p>Many database vendors don't support sequences. In these cases,
|
||
work-arounds are used, such as the following for MySQL:</p><pre class="programlisting">CREATE TABLE BATCH_STEP_EXECUTION_SEQ (ID BIGINT NOT NULL) type=InnoDB;
|
||
INSERT INTO BATCH_STEP_EXECUTION_SEQ values(0);
|
||
CREATE TABLE BATCH_JOB_EXECUTION_SEQ (ID BIGINT NOT NULL) type=InnoDB;
|
||
INSERT INTO BATCH_JOB_EXECUTION_SEQ values(0);
|
||
CREATE TABLE BATCH_JOB_SEQ (ID BIGINT NOT NULL) type=InnoDB;
|
||
INSERT INTO BATCH_JOB_SEQ values(0);</pre><p>In the above case, a table is used in place of each sequence. The
|
||
Spring core class <code class="classname">MySQLMaxValueIncrementer</code> will
|
||
then increment the one column in this sequence in order to give similar
|
||
functionality.</p></section></section></section><footer/></body></html> |