JRapid applications use a relational database schema as the persistent storage layer. For every entity defined, a database table is created with columns modeling the properties of the entity. In some cases, more than one table is created to represent a special type of relationship with other entity or collection of primitive data types. In certain other cases, such as transient variables in the POJO or formulas, the variables exist in the java object but are not persisted to the database.
Auto-generated tables and columns
Creating an entity in the designer will create a database table. The title of the table will be the same as the entity although it will not be capitalized. The table will also have an auto-increment id field created to uniquely identify each instance in cases where the user has not defined a primary key. Java objects can easily be identified as persisted to the database or not by the presence of a valid id. Objects yet to be persisted will have an id of 0 and will return a new id on calls to store() which will persist the object.
Properties of the entity with a few exceptions will also create columns in the particular table. Transient properties by definition are not persisted. Also, formulas are generated values so they will not have columns. Additional properties will map to columns of the equivalent data type. String properties will map to varchar fields, text will map to text columns, dates will map to date columns, and booleans will be represented by bits. Unique columns will be unique at the database level in addition to including a "checkUniqueFor<Property>" in the entity's service class.
References between entities where one entity has a property that is a different entity will be reflected by the containing entity having a column in its table which holds the id of referenced entity. When an entity refers to one or more, or a collection of other entities, then JRapid will generate a table that holds the references of the original entity to as many of the child entity as necessary. The new table will be <ParentEntity>_<ChildPropertyName> with any uppercases becoming lowercase. The table will contain one field for the parent table name with the id value and a second field for the property name containing the id of the referenced table.
For built-in types like text, or doubles, creating a collection functions nearly identically. The table will be created as <ParentEntity>_<Property> with the second column being the actual value, for text varchar, for floating points a double.
Viewing the database
Every JRapid project stores the database connection information in the jrapid.properties file located in the /JavaSource folder. You may easily access this information through the Database link in the Project box at the top left of the JRapid Designer screen to gain access and view your generated database.
When you click the link the JRapid Designer switches to the Files view and opens the jrapid.properties file.
Using these credentials you may connect using any SQL client. The image below shows an example for the MySQL Query Browser.
Development Database Schema
Every JRapid project is created with an associated development database schema. This schema is hosted in the JRapid development servers in the JRapid Cloud. You may access the schema using any SQL client for debugging and fine tuning your application.
Hibernate Database Configuration
Hibernate is responsible for the connection to the database and the configuration parameters are passed through the hibernate.properties file located in the /JavaSource folder of the project. Hibernate is a widely used tool to create simple java objects from persisted data.
Change Database Engine
To change the database engine used by you application you must modify the following properties in the hibernate.properties file.
For example, if switching to Oracle, the new values should be as shown below.
If you are using MySQL 5.5 as your database engine, make sure you change your dialect like this.
If you need to specify a database schema for the connection, add the following property.
During the development process the business objects you define at first may need to be modified later. JRapid's code generation process and the separation of custom code into classes that are not overwritten make it very easy to introduce changes and iterate over and over in your development process.
However, there are some situations in which the application running in the development environment may get locked in a state from which it may not recover without some human assistance. The developer must manually alter the database in order to maintain it in concordance with the hibernate layer without the need of dropping the whole schema and loosing test data.
If you do not care about loosing all the test data in the database, you may choose to drop all the tables and have them created again. To do this, click on the Manage -> Restore Database menu option.
A confirmation dialog will be shown warning about the lose of all the information stored in the database tables. Click on Submit to confirm.
JRapid drops every existing database table and refreshes the application context, causing hibernate to create all the required tables according to the current mapping files.
For example, take the following definition.
<entity label="State" menu="Places" name="State" order="name"> <property display="primary" label="Name" name="name"/> <property display="secondary" entity="Country" label="Country" name="country" required="required"/> </entity> <entity label="Country" menu="Places" name="Country" order="name"> <property display="primary" label="Name" name="name"/> </entity>
This creates the following tables in the database.
Note the id columns present in each entity table. There are no id properties defined explicitly in the entities. These properties are automatically added by JRapid when no property is defined as a primary key.
Another example that shows an extra database table required to represent a many-to-many relationship.
<entity label="Company" menu="Companies" name="Company"> <property display="primary" label="Name" name="name" required="required"/> <property display="secondary" label="Active" name="active" type="boolean"/> <property display="secondary" entity="Country" label="Country" name="country"/> <property entity="State" label="State" name="state"/> <property label="Address" name="address" type="text"/> <property collection="set" entity="Industry" label="Industries” name="industries"/> </entity> <entity label="Industry" menu="Menu" name="Industry"> <property display="primary" label="Name" name="name"/> </entity>
This creates the following tables in the database.
Including a built-in type, phone number as a set for the company will create the following structure (VARCHAR(255) is the internal phone representation):
<entity label="Company" menu="menu" name="Company"> ... <property collection="set" label="Phone Numbers" name="phoneNumbers" type="phone"/> </entity>