Roadmap

[HarryDeBoer]

In your roadmap is stated:

Next major version will be V5.2. Release date July 2016, details to come.

Can you give a hint what major and minors we can expect?

[Jon]

The big thing is the ability to publish REST services. V5.1 added the ability to act as client for a REST service, so this completes the support for REST.

Other minor items include:

• - Quick way to issue SQL statements without using a Database Resource
  - Quick way to load property files

It also includes numerous changes to support running Ebase in a cloud environment. More on this subject will be published later.

[HarryDeBoer]

Hi Jon,

>>Quick way to issue SQL statements without using a Database Resource

How does this work, and what are scenario's to use it?

when will 5.2 be out approx?

[Jon]

1. Quick way to issue SQL statements without using a Database Resource or field mappings: see below
2. Scenarios - you can continue to use Database Resources with field mappings, this new technique just gives you an alternative.
3. V5.2 release is targeted for the end of July

New SQL statement helper functions are available via services.database. There are a number of functions available covering all SQL statements. Here's a preview of the doc for the executeSelectStatement function:

executeSelectStatement(databaseConnectionName, selectStatement, callbackFunction)
* Executes a SQL select statement and passes each returned row to the specified callback function. The callback function should be
* specified with a single argument representing an object containing a key/value pair for each column in the row, see examples.
*
* The function should return true to continue execution or false to terminate execution. If the return is omitted, execution continues.
*
* Example 1: load Ebase table
*
* services.database.executeSelectStatement(
* "SAMPLES",
* "select cat_name, cat_value, creation_date from categories",
* function (columnData)
* {
* tables.categories.insertRow();
* tables.categories.categoryName.value = columnData.cat_name;
* tables.categories.categoryValue.value = columnData.cat_value;
* tables.categories.creationDate.value = columnData.creation_date;
* return true; // continue
* });
*
* Example 2: load Ebase table - the table contains columns with the same names as the columns returned by the SQL statement.
* Note that this technique cannot be used with columns of type Date, Time or DateTime.
*
* var rowData = [];
* var tableData = {rows: rowData};
* services.database.executeSelectStatement("SAMPLES", "select * from tablexyz",
* function (columnData)
* {
* rowData.push(columnData);
* return true;
* });
* // load the table
* tables.sampleTable.loadFromJSON(JSON.stringify(tableData));
* // scroll to display the first row
* tables.sampleTable.control.scrollToTop();
*
* @param databaseConnectionName the name of the Database Connection as configured in the Server Administration Application
* @param selectStatement the SQL statement to execute
* @param callbackFunction callback function called with each row of data returned from the database
* @throws SQLException

[Segi]

No offense but how is this any better/more efficient than the other way of executing a database statement without a database resource in JavaScript like this ?

Code: Select all

var sql="SELECT * FROM MyTable";

var con=system.getDatabaseConnection("MYDATABASECONNECTION");
var rs,stmt;

try {
     stmt=con.prepareStatement(sql);
     rs=stmt.executeQuery();

     while (rs.next()) {
     }
} catch (e) {
     // Dump the SQL for debugging purposes
     print("An error occurred reading the database with the query " + sql);
     print(e);

     if(rs) rs.close();
     if(stmt) stmt.close();
     if(con) con.close();

     event.stopExecution();
} finally {
     if(rs) rs.close();
     if(stmt) stmt.close();
     if(con) con.close(); 
} 

There aren't any date/time restrictions when doing it this way and it is easier to manage because there's no need for a callback function so you can see exactly what the code does without jumping around and with less code.

[Jon]

It isn't better or more efficient, it's just a little less code. Plus I think it's much more accessible for non-Java people.

[Steve James]

Any news? Publishing REST! Excellent.

I know I am chasing the gun but it's no longer the end of July

Thanks

[Jon]

Yes sorry about that. The development is all completed but we still need to do the documentation and we've run into summer holidays. I think it will be another month.

[Steve James]

Arghhh ,

I was really hoping for publishing RESTful services asap as I am trying to get momentum around OpenData. Internally I want to use Ebase to dynamically create csv files and publish the same data over an API.

[Steve James]

Hi, out of interest how do you protect from sql injection if a select statement is built from field values?

Obviously the following wouldn't be safe.

Code: Select all

var selectStmt = "select * from tablexyz where value = '" + fields.value.value + "'"; 
services.database.executeSelectStatement("SAMPLES", selectStmt, 
* function (columnData)....... 

[Jon]

There isn't any protection against SQL Injection when using this technique. If you think SQL Injection is possible in any particular circumstance, it will be safer to use a Database Resource.