Defining SQL Queries

The database connector reads its definitions from a configuration file. By default this file is located in <frevvo-home>/tomcat/webapps/database/WEB-INF/etc/configuration.xml but you can [[#Configuration_File_Location | change the location]].

This is an example configuration file:

<pre>
<dbconnector version="2.0">

   <queryset name="myStore" timeStampFormat="yyyy-MM-dd HH:mm:ss"
                            dateFormat="yyyy-MM-dd"
                            xmlDateFormat="yyyy-MM-dd">

      
      <resource-def>
<url>jdbc:hsqldb:file:mystore</url>
<driver>org.hsqldb.jdbcDriver</driver>
<user>sa</user>
<password></password>
      </resource-def>

      <query name="allOrders">
         <retrieve>
     <statement>
        SELECT * FROM "orders"
     </statement>
</retrieve>
      </query>

<query name="orders" autocreate="true">
         <retrieve> 
      <statement>
                SELECT * FROM "orders" WHERE "orderId"='{orderId}'
     </statement>
</retrieve>

</query>

      <query name="allProducts">
        <retrieve>
          <statement>
               SELECT * FROM "products"
     </statement>
</retrieve>
      </query>

</queryset>

</dbconnector>
</pre>

The xml elements in the file are as follows:

* The '''queryset''' element groups together a Data Source definition and a list of '''query''' elements.
* The SQL queries defined under each '''query''' element will be executed against the respective Data Source.
* Each '''query''' element defines a SQL statement for each CRUD operation (create, retrieve, update, delete).
* You can define as many '''queryset''' elements as required with each pointing to a different Data Source. In essence, you can have one instance of the database connector working with multiple databases.

If you update the configuration file, the database connector will pick up changes automatically.

===== SQL Statements =====

You define the scripts that will work with your database in the configuration file. For example, the sample configuration file defines a '''query''' called ''customers''. That query assumes that a table such as the one below exists in your Data Source.

<pre>
CREATE TABLE customers (
customerId INT,
firstName VARCHAR(50),
lastName VARCHAR(50)
)
</pre>

The SQL statements are nested inside a <query> element and one query can include up to four SQL statements. This is part of the SQL-to-Browser translation—four is the “magical” number because under the covers the connector is translating the four basic SQL functions: create, retrieve, update and delete (CRUD) to the four basic browser functions of POST, GET, PUT and DELETE. That is reflected in the children elements of the <query> element: <create>, <update>, <retrieve> and <delete>.

One query cannot have two SQL statements of the same type. If you need two different <retrieve> statements (for example, Select * from customers and Select * from Product), you’ll need two different <query> elements. A query may have fewer than four SQL statements—if users can’t delete data from your database via your forms, your query does not need a <delete> operation.

Here is the retrieve operation for query '''customers'''. The SQL statement returns all records from the customers table that match a given customer id:

<pre>
    <query name="customers">
<retrieve>
         
    <statement>
        SELECT * FROM customers
        WHERE customerId='{customerId}'
            </statement>
        </retrieve>

</query>

</pre>

You can use any valid SQL statement in the configuration.

Note the string '''{customerId}'''. The database connector SQL statements are actually templates that are resolved at run time using values passed in the http request. In the example above, if there is a parameter in the http GET request that hits the connector with customerId=1234 than the statement would return the record for customer 1234.

=== Auto Create Rows ===

You can set the attribute '''autocreate''' in a '''query''' element.

This property applies only when users submit an HTTP PUT request to the database connector. The property tells the database connector to create a new row in the database if one doesn't exist already meaning that the connector will run the '''create''' statement automatically if the '''update''' statement fails. In summary:

* If the user is updating an existing record, the Update statement will work as it normally does and the autocreate function won’t kick in.
* If the user is adding a new record, the '''update''' statement will fail (by design, because the record cannot exist if the user hasn’t added it yet) and the Connector will then run the '''create''' statement.

The autocreate feature is particularly useful when working with frevvo's '''repeat''' control. frevvo's repeat control gives you the ability to work with dynamic collections, for instance: customers, cars, addresses, dependents and others. When the user loads the form, the form may be initialized with some items (we will see how to do that with frevvo later). If the user adds new items to the collection and submits the form, those items will be automatically added to the database if '''autocreate=true'''

This behavior is actually enabled by default so if you want to turn it off you can set autocreate to false.

=== Auto Delete Rows ===
The autodelete feature is useful when working with frevvo '''repeat''' controls. Imagine you have a collection of elements in the form that were initialized from a database. If you eliminate an item in the collection and submit the form, the connector will automatically remove the item from the database. For that to happen, set the attribute '''autodelete''' to '''true''' in the query element.

<pre>
<query name="customers" autocreate="true" autodelete="true" deleteKey="customerId">
</pre>

Behind the scenes, the connector actually compares the items in the database with what is submitted in the form. That comparison criteria is based on a key that you define with the attribute '''deleteKey''' (required). The deleteKey value is normally the name of the primary key in the table that contains the repeat items.

=== Dates and Timestamps ===

If you define a date, time or timestamp column in your database the database connector will need to know the format of those dates in order to properly parse them. Also, when the connector reads the dates from the database, it will transform them to XML dates and those also can have a specific format. You can define both the databse and the xml date formats. Those definitions are done by defining attributes in the '''queryset''' element. For instance:

<pre>
<queryset name="myStore" timeStampFormat="yyyy-MM-dd HH:mm:ss" dateFormat="yyyy-MM-dd" xmlDateFormat="yyyy-MM-dd">
   <query name="customers">
<retrieve>
<statement>
           SELECT * FROM customers
           WHERE customerId='{customerId}'
         </statement>
       </retrieve>
    </query>
</queryset>
</pre>

In this case, the time stamp and date formats in the database are "yyyy-MM-dd HH:mm:ss" and "yyy-MM-dd" respectively. That is the format the database connector will use to parse the date types from the database.

On the other hand, when the XML documents is created, the date format will follow the definition of the attribute '''xmlDateFormat'''.