Regarding lines 118 - 125, if attr is null, what should type default
to? I really don't think that will work, honestly.
In my own extended types, I do processing based on the type
attribute... so does the EnumType, for that matter, since it
determines whether to convert to int or string based on the database
type. So, seems like the long-term "right" solution is to make sure
that DbAttribute is something correct...
As for debugging, I put the breakpoint in and started walking back up
the stack.
As predicted, it's QualifierTranslator. More specifically, the
paramsDbType method of QueryAssemblerHelper is returning null.
So, digging a little further, the point at which the paramsDbType
returns null is on the unary operator check.
Lines 286-291 of QueryAssemblerHelper:
protected DbAttribute paramsDbType(Expression e) {
int len = e.getOperandCount();
// ignore unary expressions
if (len < 2) {
return null;
}
e.getOperandCount returns 1.
e is an instance of ASTList, which always returns 1 for the operand
count.
So, you get the null DbAttribute there, which is then passed into
QueryTranslator.appendList, from there into
QueryTranslator.appendLiteral,
In appendLiteral, matchingObject is going to be false for any type
that isn't a data object
(which suggest that /any/ extended type is going to have issues with
inExp... something I will test tomorrow).
So, QueryAssemblerHelper.appendLiteral gets called ; again, some
special handling is going on for data objects...
so then we jump to QueryAssemblerHelper.appendLiteralDirect, where I
found this comment:
// we are hoping that when processing parameter list,
// the correct type will be
// guessed without looking at DbAttribute...
Which, of course, isn't happening since the null dbattribute
precludes the extended type stuff from having a chance to work their
magic.
Thoughts?
Robert
On Jul 27, 2007, at 7/274:18 PM , Andrus Adamchik wrote:
Also there may be another way to fix it by tracking down why 'attr'
is null in the first place (putting a breakpoint in
QueryAssembler.addToParamList(...) method, line 86, to see who is
calling it with NULL). I think the QualifierTranslator is to blame
here - it can't always match a value against an attribute. I expect
this to be a more complex fix.
Note that the two fixes are independent from each other, and if
they work reliably (and won't require rewriting all translation
logic :-)), they both will be a good addition to Cayenne.
Andrus
On Jul 28, 2007, at 12:07 AM, Andrus Adamchik wrote:
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
