Ebean调用存储过程并将ResultSet转换为Model

Question

I'm working in report module, in order to do that I'm creating different stored procedures. I create the procedure with in parameters and then create a class to map the row (resultSet) I think that's the best way to work arround performance and clarity.( what do you think about that? )

I'm using play framework and ebean orm (2.7.7)

I'm calling the store procedure and getting the resultSet, but I would like to use ebean in order to cast automaticly the row to model ... other option is take the row-cell and cast it in a property but I'm trying to avoid it.

This is the current approach
Is this the best way to call an stored procedure?

    Transaction tx = Ebean.beginTransaction();
    String sql = "{CALL report(?, ?, ?, ?, ?, ?)}";

    CallableStatement callableStatement = null;

    try {

        Connection dbConnection = tx.getConnection();

        callableStatement = dbConnection.prepareCall(sql);

        callableStatement.setInt(1, 3);
        callableStatement.setInt(2, 5);
        callableStatement.setInt(3, 2013);
        callableStatement.setInt(4, 1);
        callableStatement.setInt(5, 2014);
        callableStatement.setInt(6, 5);

        ResultSet rs = callableStatement.executeQuery(sql);


        while (rs.next()) {
            //HOW TO CONVER row -> model ?
        }

        Ebean.commitTransaction();

    } catch (SQLException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    }

I've discarded RawSQL and Query because received an error
RuntimeException: Error parsing sql, can not find SELECT keyword in: xxxxx

Also I found other option... using CallableSql

 String sql = "{call sp_order_mod(?,?)}";

 CallableSql cs = Ebean.createCallableSql(sql);

 cs.setParameter(1, "turbo");
 cs.registerOut(2, Types.INTEGER);

 Ebean.execute(cs);

 // read the out parameter
 Integer returnValue = (Integer) cs.getObject(2);

but in this case I need to return a ResultSet not simply parameter .

Answer 1

I'm going to share my own solution.

1. I get a class called ResultSetUtils.(you can google it some implementation)

2. I added a generic method in order to return a typed list from resultset

    public static <T> List<T> populateInList(Class<T> c, final ResultSet rs) { List<T> listTyped = new ArrayList<T>(); try { if (rs != null) { while (rs.next()) { T o = c.newInstance(); // MAGIC LINE populate(o, rs); listTyped.add(o); } rs.close(); } } catch (final Exception e) { // TODO Auto-generated catch block System.err.println(e.getMessage()); } return listTyped; } 

   This class to do the population use org.apache.commons.beanutils package BeanUtils.populate(bean, propertiesRealName);

3. Using

    private static void callingProcedureTest() { Logger.debug("Init callingProcedureTest"); Transaction tx = Ebean.beginTransaction(); // String sql = "{CALL sp_report_test(3, 5, 2013, 1, 2014, 5)}"; String sql = "CALL sp_report_test(?, ?, ?, ?, ?, ?);"; try { Connection dbConnection = tx.getConnection(); CallableStatement callableStatement = dbConnection.prepareCall(sql); callableStatement.setInt(1, 3); callableStatement.setInt(2, 5); callableStatement.setInt(3, 2013); callableStatement.setInt(4, 1); callableStatement.setInt(5, 2014); callableStatement.setInt(6, 5); Logger.debug("SQL > " + sql); ResultSet rs = callableStatement.executeQuery(); Class<ReportTestResult> c = ReportTestResult.class; //************** MAGIC LINE, converting ResultSet to Model List<ReportTestResult> listResult = ResultSetUtils.populateInList(c, rs); for (ReportTestResult item : listResult) { Logger.debug("item.firstName> " + item.firstName); Logger.debug("item.lastName > " + item.lastName); Logger.debug("item.year > " + item.year); } Ebean.commitTransaction(); } catch (Exception e) { Ebean.rollbackTransaction(); // TODO Auto-generated catch block e.printStackTrace(); }finally{ Ebean.endTransaction(); } } 

Plus about architecture and implementation

For each report I'm going to create:

• a Result class (eg ReportTestResult)

  • intention: represent a row of report | simple DTO

• a Param class (eg ReportTestParam),

  • intention: represent the parameters (inputs / ouputs), filters of the report

    This class should implements

     public interface ReportParam { public int countParameteres(); public void setParametersInCallableStatement(CallableStatement callableStatement) throws SQLException; } 

• a Report class (eg ReportTestReport) this class should extends ReportBase

  • intention: Knows the stored procedure's name, parameters and dto result

     public class ReportTestReport extends ReportBase<ReportTestResult, ReportTestParam> { @Override protected String getProcedureName() { return STORED_NAME; } } 

• many Adapters...

  • Each report could displayed in different charts, In this case I'm using HighCharts. Order to arrange it, I'm creating different adapters to do that.

    EG:
    class ReportTestHighChartsAdapter

    • intention: convert a list of ReportTestResult to series and configure different options of report (eg, title, xAxis etc)

       public OptionsHC buildColumnReportV1(){ OptionsHC optionChart = new OptionsHC(); optionChart.chart = new ChartHC("column"); this.setTitle(optionChart); optionChart.yAxis = new AxisHC(new TitleHC("Fruit eaten")); ..... return optionChart; } 

      • OptionsHC is a class that represent option obj in the HighCharts framework.

      • The final step is converting OptionHC to Json and use it in JavaScript (common use of highCharts)

What's ReportBase?

ReportBase class has the strategy to implements the final called to DB, also manage the transaction

        public class ReportTestReport extends ReportBase<ReportTestResult, ReportTestParam> {

        ...

            protected List<TResult> execute(Class<TResult> classT) {

                List<TResult> resultDTO = null;

                CallableStatement callableStatement = null;

                Logger.debug("Running procedure> " + this.getProcedureName());

                Transaction tx = Ebean.beginTransaction();

                String sql = ProcedureBuilder.build(this.getProcedureName(), this.countParameters());

                Logger.debug("SQL > " + sql);

                try {

                    Connection dbConnection = tx.getConnection();

                    callableStatement = dbConnection.prepareCall(sql);

                    this.getFilter().setParametersInCallableStatement(callableStatement);

                    ResultSet rs = callableStatement.executeQuery();

                    resultDTO = ResultSetUtils.populateInList(classT, rs);

                    Ebean.commitTransaction();

                    Logger.debug("commitTransaction > " + sql);

                } catch (Exception e) {
                    Ebean.rollbackTransaction();

                    Logger.debug("rollbackTransaction > " + sql);

                    // TODO Auto-generated catch block
                    e.printStackTrace();
                }finally{
                    Ebean.endTransaction();
                }

                return resultDTO;
            }

        ...

        }

Answer 2

Currently the support for stored procedures in Ebean is not orientated to what you are trying to do. Hence you are not going to get much joy from using CallableSql or RawSql.

>> a class to map the row (resultSet) I think that's the best way to work around performance and clarity

Yes, I can understand your motivation.

>> How to convert ResultSet into model

Currently there is no good solution. The best solution would be to enhance RawSql so that you can set a ResultSet onto it. One of the things RawSql does is provide the mapping of resultSet columns to model properties and that is what Ebean needs internally. The enhancement/code change would be to be able to set a resultSet onto the RawSql object ... and get Ebean internally to skip the creation of the resultSet ( preparedStatement, binding parameters and executeQuery()). In terms of Ebean internals this is all done in the CQuery.prepareBindExecuteQueryWithOption() method. That is, if the RawSql has already provided a resultSet skip those things.

The big benefit of doing this rather than just rolling your own row -> model mapping code is that the resulting beans would all still have lazy loading / partial object knowledge etc. They would behave exactly like any other beans that Ebean builds as part of it query mechanism.

So that said, I'm personally away for a week ... so you aren't going to hear back from me until after that. If you want to get into it yourself then internally CQuery.prepareBindExecuteQueryWithOption() is the code you will need to modify.

If you have been following the ebean google group you'll know that but just in case you have not been note that the Model and Finder objects from Play have been incorporated into Ebean just in the last week. This helps both projects ... reduces confusion etc. The Ebean source in github master is at 4.0.4 and the bytecode enhancement in 4.x is different and I don't believe supported in Play.

I'm basically going offline for a week now so I'll look back into this after that.

Cheers, Rob.