Skip to content

SQLEP 1.1.x POJO modelling

Vladimír Hudec edited this page Apr 5, 2015 · 1 revision

###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

Clone this wiki locally