Synapticloop :: h2zero

Views.

Views, similar to tables are a base object that then generates the model objects for interaction through the java code. As such they are relatively straight-forward, however there are a few differences.

Views are read only, consequently, the following actions do not apply to a view

• Updaters, and
• Deleters

Fundamentally, views are just a pre-defined query that are run against the existing database tables to provide a cut downdata set for easy access

Views are optional and are not required to be present.

"views": [
	{
		"name": "user_type_admin",
		"asClause": "select * from user_type where user_type = 1",
		...
	},
	{
		"name": "user",
		...
	},
]

Each view MUST have a key of name which will map to the database schema and model object in CamelCase naming convention.

For example the user_type table name above will generate the following model object

The user_type table is a Constant Model and differs from normal other models in that constant tables cannot be updated, deleted or inserted into as they are pre-generated by h2zero.

• src/main/java/synapticloop/sample/h2zero/model/UserType.java
  [plain java | pretty-printed]

The user table name above will generate the following model object

• src/main/java/synapticloop/sample/h2zero/model/User.java
  [plain java | pretty-printed]

The user table is a Regular Model object that maps to the underlying MySQL table and h2zero will allow generation of all create, read, update and delete (CRUD) methods.

Models in General

Models come in two flavours, regular and constant. They both share some base features and functionality asdetailed below:

BINDER

// the binder is unused in code, but will generate compile problems if this 
// class is no longer referenced in the h2zero file. Just a nicety for
// removing dead code
@SuppressWarnings("unused")
private static final String BINDER = Constants.USER_TYPE_binder;

As mentioned in the comments above the field, the BINDER is only used as a compile time error so that dead code can be removed. Most of the generated code contains this code that references the constant. This will ensure that when model names are changed, or any of tyhe interaction names are changed (e.g. finders, questions, counters etc.)

PRIMARY_KEY_FIELD

public static final String PRIMARY_KEY_FIELD = "id_user_type";

This is a reference to the primary key field in the database. Every table (and therefore every model) must have a primary key on it.

Member variable declarations

Each field that is attached to the table will generate a declaration.

private Long idUserType = null;
private String nmUserType = null;

Constructor

Every model has a constructor with a signature that contains all of the fields. Despite the fact that you cannot create new constants, the constant models still include a constructor for use with finders, counters and questions.

public UserType(Long idUserType, String nmUserType) {
	this.idUserType = idUserType;
	this.nmUserType = nmUserType;
}

Getters

/*
 * Boring ol' getters and setters 
 */

public Long getIdUserType() {return(this.idUserType);}
public String getNmUserType() {return(this.nmUserType);}

Getters are generated (in condensed format) for each field on the table. No setters are generated for constant models as you may not change constants.

String methods

public String toString() {
	StringBuilder stringBuilder = new StringBuilder();
	stringBuilder.append("Model[UserType]\n");
	stringBuilder.append("  Field[idUserType:" + this.idUserType + "]\n");
	stringBuilder.append("  Field[nmUserType:" + this.nmUserType + "]\n");
	return(stringBuilder.toString());
}

public String toJsonString() {
	// !!! work in progress !!!
	StringBuilder stringBuilder = new StringBuilder();
	stringBuilder.append("{\n");
	stringBuilder.append("  \"model\": {\n");
	stringBuilder.append("    \"name\": \"UserType\",\n");
	stringBuilder.append("    \"fields\": [\n");
	stringBuilder.append("     { \"name\": \"idUserType\", \"value\": " + this.idUserType + " }, \n");
	stringBuilder.append("     { \"name\": \"nmUserType\", \"value\": \"" + this.nmUserType + "\" }\n");
	stringBuilder.append("    ]\n");
	stringBuilder.append("  }\n");
	stringBuilder.append("}\n");
	return(stringBuilder.toString());
}

public String getJsonString() {
	return(toJsonString());
}

The string methods are automatically generated for each model. As the comment notes above, it is a work in progress. Care must be taken when utilising this method on sensitive information contained within the model, e.g. passwords, credit card details etc.

The getJsonString() method signature above is for JSTL or templar referencing for output.

Regular Models

Regular models are the default generation for h2zero and, as opposed to constants, allow access to insert new rows into the database and have access to the full range of interactions. This is the foundation for the h2zero generation.

Additional methods and member variables

In addition to the general generation mentioned above, for each of the constant models, the following field and method signatures are generated:

Static Final Member Variable References

private static final String SQL_INSERT = "insert into user values (?, ?, ?, ?, ?, ?, ?, ?)";
private static final String SQL_UPDATE = "update user set id_user_type = ?, fl_is_alive = ?, num_age = ?, nm_username = ?, txt_address_email = ?, txt_password = ?, dtm_signup = ? where " + PRIMARY_KEY_FIELD + " = ?";
private static final String SQL_DELETE = "delete from user where " + PRIMARY_KEY_FIELD + " = ?";
private static final String SQL_ENSURE = "select " + PRIMARY_KEY_FIELD + " from user where id_user_type = ? and fl_is_alive = ? and num_age = ? and nm_username = ? and txt_address_email = ? and txt_password = ? and dtm_signup = ?";

The basic CRUD operations for the model. Each model knows how to create, read, update and delete itself from the database. There is also an 'ensure' mode, which will be covered later in this documentation set.

Constructors

Interactions

Please see the method signatures page for information about usage patterns for the various method signatures that are generated.

inserts - CRUD operators (and then some)

Insert methods are not valid and consequently not generated on views as they create their rows from the asClause,

ensure - CRUD operators (and then some)

Ensure methods are not valid and consequently not generated on views as they create their rows from the asClause,

updates - CRUD operators (and then some)

Update methods are not valid and consequently not generated on views as they create their rows from the asClause,

insert or updates - CRUD operators (and then some)

Insert or update methods are not valid and consequently not generated on views as they create their rows from the asClause,

deletes - CRUD operators (and then some)

Delete methods are not valid and consequently not generated on views as they create their rows from the asClause,

refreshes - CRUD operators (and then some)

Refresh methods are not valid and consequently not generated on views as they create their rows from the asClause,

Getters and setters

public void getIdUser(Long idUser)

Only getters are generated.