Re: cay-832 (enums in in exp)

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Fri Jul 27 2007 - 17:07:42 EDT

  • Next message: Andrus Adamchik: "Re: cay-832 (enums in in exp)"

    On Jul 27, 2007, at 9:08 PM, Robert Zeigler wrote:

    > So, I'm interested in getting this issue resolved rather quickly,
    > which means I'm interested in jumping into the code.
    > But the implementation details of the expression parsing is not
    > code I've spent a lot of time looking at.
    > Any pointers on where to start digging? I've rummaged through some
    > of the expression code, some of the db adapter/sql translator code,
    > and took a look at the enum converter in the java-15 subproject.
    > But I don't have a good sense of the big picture of how all of the
    > pieces fit together.
    > So... any pointers are appreciated (normally, I would just keep
    > digging on my own, but I'm in a time crunch to finish a project
    > right now, so the faster I can
    > fix this and patch it... :)
    >
    > Thanks!
    >
    > Robert

    Hi Robert,

    EnumType in java-15 subproject should be invoked by Cayenne runtime
    when binding the value. Judging from the behavior you observed, it is
    not. So here is the relevant part of the stack trace:

    at org.hsqldb.jdbc.jdbcPreparedStatement.setObject(Unknown Source)
    at org.apache.cayenne.access.trans.QueryAssembler.initStatement
    (QueryAssembler.java:119)
    at org.apache.cayenne.access.trans.QueryAssembler.createStatement
    (QueryAssembler.java:98)

    QueryAssembler.java looks like this:

    118 if (attr == null) {
    119 stmt.setObject(i + 1, val);
    120 }
    121 else {
    122 int type = attr.getType();
    123 int precision = attr.getPrecision();
    124 adapter.bindParameter(stmt, val, i + 1, type, precision);
    125 }

    Cayenne prematurely bailing out of correct PreparedStatement binding
    algorithm (that starts on line 122) and opting for a quick and dirty
    'PreparedStatement.setObject(..)' on line 119 is what's causing the
    problem. Looking at this now, the condition check looks overly
    pessimistic and 'attr == null' does not justify skipping the correct
    flow. I think we may get rid of the "if" part and always execute
    "else" (just check for null on lines 122 and 123). That would require
    some regression testing, but logically it seems like it should work
    and is a better approach.

    Let us know if that worked for you (and didn't break the rest of
    Cayenne) - and we'll fix it in SVN.

    Thanks
    Andrus



    This archive was generated by hypermail 2.0.0 : Fri Jul 27 2007 - 17:08:11 EDT