-
Notifications
You must be signed in to change notification settings - Fork 16
SQLEP 1.1.x POJO modelling
###The tutorial is updated for SQLP 2 and SQLEP 1.3
##Introduction The new features of the SQL Processor Eclipse plugin (SQLEP) version 1.1.0 are
- POJO modelling and source code generation
- POJO model generation based on DB model
The best approach is to put all new control directives into a separate file pojo.qry
. It has to be located alongside the statements.qry
(contains the runtime SQLP artifacts) and definitions.qry
(contains the control artifacts described in the tutorial SQLEP 1.1.x Basic Tutorial):
This tutorial is based on the sample project https://github.com/hudec/sql-processor/tree/master/sql-samples/simple-jdbc-pojo.
##POJO modelling and source code generation
The SQLEP enables POJO definition using the Xtext grammar, like in the following snippet from the pojo.qry
:
package org.sqlproc.sample.simple.model {
pojo Library serializable 1 {
id : java.lang.Long primaryKey
name : java.lang.String required
equals ::: id
hashCode ::: id
toString ::: id name
}
}
After saving the pojo.qry
- the POJO Library.java
is automatically generated in the directory src-gen/org/sqlproc/sample/simple/model
:
package org.sqlproc.sample.simple.model;
import java.io.Serializable;
public class Library implements Serializable {
private static final long serialVersionUID = 1L;
public Library() {
}
public Library(String name) {
this.name = name;
}
private Long id;
public Long getId() {
return id;
}
public void setId(Long id) {
this.id = id;
}
// other getters and setters
}
To force this feature in the IDE, the project has to be imported with the following snippet in the pom.xml
:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>src-gen</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
....
</build>
###Packages The top level element in the POJO modelling is the package:
package org.sqlproc.sample.simple.model {
...
}
There can be a couple of packages and any package can have a suffix
package org.sqlproc.sample.simple.model {
...
}
package org.sqlproc.sample.model.impl suffix Impl {
...
}
In the previous example the package org.sqlproc.sample.model.impl
has a suffix Impl
. The result effect is that every generated Java class has a name suffix with the same value.
###POJOs Inside the package there are pojos' definitions
pojo Library {
...
}
POJO can be accompanied with the modifiers
- prefix
abstract
- the result Java class is abstract - prefix
final
- the POJO definition won't be overwritten in the case the pojos are generated from DB model - postfix
extends AnotherPojo
- the result Java class extends AnotherPojo class - postfix
discriminator someValue
- used in special cases of inheritance, please see More-inheritance-tutorial - postfix
serializable someNumber
- the result Java class is serializable with the specific value of serialVersionUID
All the generated Java classes can be forced to implement required interfaces. It can be done as in the following example
package org.sqlproc.sample.simple.model {
implements java.io.Reader
implements java.io.Serializable
pojo Library {
id : java.lang.Long primaryKey
...
}
All the generated Java classes can be forced to extend one Java class. It can be done as in the following example
package org.sqlproc.sample.simple.model {
extends org.sqlproc.sample.simple.model.BasePojo
pojo Library {
id : java.lang.Long primaryKey
...
}
###Attributes Inside the POJO there are attributes' definitions. The attribute can be native
id _int
or it can be another of Java class type
id : java.lang.Long
or it can be a reference to another POJO
account :: BankAccount
In all cases the content assist can help. For example when you press a Ctrl-Space after a :
control character, a list of all Java classes on the classpath is offered.
More, the attributes can be of generic type
library : java.util.List <:Media>
or array
contacts :: Contact[]
Attributes can be accompanied with the postfix modifiers
-
required
- in the case the related column in DB table is NOT NULL. This attribute becomes a parameter in the Java class constructor. -
discriminator
- the related column in DB table is discriminator -
primaryKey
- the related column in DB table is primary key
For every attribute one getter and 2 setters are generated. For example for the attribute id
in the POJO Library
pojo Library serializable 1 {
id : java.lang.Long primaryKey
...
the following code is generated
private Long id;
public Long getId() {
return id;
}
public void setId(Long id) {
this.id = id;
}
public Library _setId(Long id) {
this.id = id;
return this;
}
The setter _setId
can be used in the Dutch style code
Library library = new Library()._setId(1L)._setName("Mestska knihovna");
###Methods Inside the POJO there can be also the next methods' definitions
equals ::: id
hashCode ::: id
toString ::: id name
The related methods in the generated Java class are created. After the control characters :::
there's a list of all attributes, which are utilized inside the method body. For example for the previous model snippet the following code is generated for the POJO Library
@Override
public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
Library other = (Library) obj;
if (id != other.id)
return false;
return true;
}
@Override
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + (int) (id ^ (id >>> 32));
return result;
}
@Override
public String toString() {
return "Library [id=" + id + ", name=" + name + "]";
}
public String toStringFull() {
return "Library [id=" + id + ", name=" + name + "]";
}
The difference between toString
and toStringFull
is that in the toString
no referenced attributes are used. This is to prevent the circular references.
##POJO model generation based on DB model Please see SQLEP 1.1.x POJO generation
##Table of Contents
- SQL Processor Home
- SQL Processor News
- SQL Processor Eclipse Plugin Home
- SQL Processor Eclipse Plugin News
- SQLP and SQLEP Tutorials
- SQLEP Control directives
- Basic Tutorials
- 10 minutes Tutorial
- Simple Tutorial
- CRUD Tutorial
- Associations Tutorial
- Inheritance Tutorial
- More inheritance Tutorial
- Custom Types Tutorial
- Stored procedures Tutorial
- IDE Setup and Coding Standards
- Catalog (JPA) Sample
- Catalog (Hibernate) Sample
- Catalog (Spring) Sample
- Advanced catalog (Spring) Sample
- The Reference Guide
- The Eclipse Plugin (SQLEP) Tutorials
- SQLEP 1.1.x Basic Tutorial
- SQLEP 1.1.x POJO modelling
- SQLEP 1.1.x POJO generation
- SQLEP 1.2.x Changes Tutorial
- SQLEP 1.2.x META SQL gener.
- SQLEP 1.2.x DAO modelling
- SQLEP 1.2.x DAO generation
- SQLP 2.0 and SQLEP 1.3 Tutorial
- SQLEP 1.3.1 Tutorial
- SQLP 2.1 and SQLEP 1.4 Tut.
- SQLP 2.1.1 and SQLEP 1.5 Tut.
- SQLP 2.2.0 and SQLEP 1.6 Tut.
- SQLP 2.2.1 and SQLEP 1.7 Tut.
- SQLP 2.2.2 and SQLEP 1.7.1 Tut.
- SQLEP 1.7.3 Tutorial
- SQLEP 1.7.4 Tutorial
- SQLEP 1.7.5 Tutorial
- SQLEP 1.7.6 Tutorial
- SQLEP 1.7.7 Tutorial
- SQLP 2.2.6 and SQLEP 1.7.8 Tut.
- SQLP 2.3.0 and SQLEP 1.8.0 Tut.
- SQLEP standalone
- SQLP 2.4.0 and SQLEP 1.9.4 Tut.
- SQLEP 2.0.0 Tutorial
- Tutorials archive