Our Next Race – Beta Release

Do you need to have a list of all of your races for 2019? Want to track them? Want to avoid too many races? Race conflicts? Avoid racing back to back when your coach says not to?

Visit www.ournextrace.com and create your race list for 2019 and beyond. Scroll through a curated list of local races and decide what interests you. Then keep track of where you are staying, what you paid or volunteer status.

The service is free. We will have coupons and codes for you to sign up. We make our money by partnering with Race Directors who want you and your friends to sign up.

Privacy? Of course your data is your data. None of you personal data or email will ever be sold or shared with partners. You only share an email and optionally a zip code and we’ll serve up you list 24/7.

Sign up now and share the word about www.ournextrace.com

To provide product suggestions, suggest more races to add to the list, or just ask questions contact us here

Using your tablet you can see at a glance what is coming up and avoid conflicts and over commitments

Our Next Race FAQ

Q – What does this cost?
A – Nothing. There is no fee. This is a an educational project for us. We will hope to raise revenue with ads and partnerships with race directors

Q – How do I login?

A – You can use your own email and password or use Facebook and Google to authenticate. We only use the email and none of your friends list or photos are accessed.

DB2 Arrays with Spring Boot and myBatis

Working project showing the many ways to invoke a DB2 stored procedure with an Array as an IN parameter. Using Spring boot to ease the
use of JUnits and application configuration.

See the complete code examples here

Overall Steps

1 – Create the Type

In order to use Array you will need to create a custom type in DB2. Work with DBA on making this public and not tied to an application specific SCHEMA. For this demo the Array is tied to “IJUDY” schema. This is for educational purposes only and not intended for production.

DDL Sample

'CREATE TYPE "IJUDY"."STRING_ARRAY" AS VARCHAR(128 OCTETS) ARRAY [256];'


### 2 - Create the SP using the Type
See the file GET_BY_EMPNUMBERS.sql for a SP that quries the default EMPLOYEE database IBM;s SAMPLE db

 

3 Create Mapper or DAO Classes to Invoke the SP

Please see

 https://lalitjc.wordpress.com/2013/07/02/different-ways-of-calling-stored-procedure-using-spring/ for the inspiration for this article. I went ahead and made a DB2/Array specific version of his article.

The most elegant way is to use the Spring mapper. The only caveat is you will need to create your own ‘org.apache.ibatis.type.TypeHandler‘. I find this odd as I was able to invoke the SP using JDBC4 and non-vendor specific calls. I think JDBC 3 drivers or earlier may be different.

See the EmployeeMapper.java interface for exact details

Pay special attention to the Annotation syntax. Especially to the how the IN parameter is defined with the custom TypeHandler

“#{I_EMP_ID_ARRAY, jdbcType=ARRAY, mode=IN, typeHandler=com.ijudy.mapper.typehandler.Db2ArrayTypeHandler}

EmployeeDaoImpl

There are 3 implementations for the DAO class. Based on how low level you want to go you can use plain JDBC calls or the more elegant and versatile Spring classes. When using Spring in our implementation we ended up turning off AUTO commit and also not caching the the Prepared Statement. These changes may not be required for your design but something to consider

getEmployeesCallableStatementCreator – Uses the jdbcTemplate and overrides the below interface

@Override
public CallableStatement createCallableStatement(Connection connection) throws SQLException

getEmployeesCallableStatment – Uses the jdbcTemplate only for the connection and has no real Spring dependencies and is the closest to straight
direct JDBC calls than the other methods. Make sure to close all of your resources.

getEmployeesSimpleJdbcCall – This is all Spring and has the most complexity but also the most versatility. The connection and resources should be managed by Spring and you should not have to deal with connection management nor low level details. Again, when we were using this Spring design in our implementation we ended up turning off AUTO commit and also not caching the the Prepared Statement otherwise the connection seemed to get consumed and locked and reusable when invoked again. We would see the data come back the first time and the internally roll back and return a 100 (NO ROWS FOUND) the second time. There would be no SQLException just the illusion of no records found. The connection would not return data again until after the connection timed out. This was quite frustrating. These changes may not be required for your design but something to consider.

 

CallableStatement, Java, Jdbc, SimpleJdbcCall, Spring, Stored function, Stored Procedure DB2