On 12/09/2010, at 2:57 AM, Adrian Crum wrote: > --- On Sat, 9/11/10, Scott Gray <scott.g...@hotwaxmedia.com> wrote: >> Currently >> JdbcValueHandler.BlobJdbcValueHandler will accept byte >> arrays and Blobs (reluctantly) but not ByteBuffers. >> The problem is that the service engine uses ByteBuffer as >> the attribute type for attributes created based on blob >> entity fields and crud services fail due to this because >> they don't attempt to convert them before using something >> like <create-value/>. >> >> So what is the correct behavior? Should the service >> engine be using a different type or should the >> JdbcValueHandler be more flexible? > > I'm pretty sure the current JdbcValueHandler code contains the same logic as > the original switch statement, but I might have missed something.
Thanks for the info, it looks like the code used to check for byte[] then ByteBuffer and then finally Blob, snippet below from about a year ago: case 12: if (fieldValue instanceof byte[]) { sqlP.setBytes((byte[]) fieldValue); } else if (fieldValue instanceof ByteBuffer) { sqlP.setBytes(((ByteBuffer) fieldValue).array()); } else { sqlP.setValue((java.sql.Blob) fieldValue); } break; > That code is a bit messy because it's trying to convert multiple types to a > BLOB - in an effort to maintain backward compatibility. You can see remarks > in there about that. > > I introduced new data types - Object and byte[], to help make things less > ambiguous and hopefully provide a path toward cleaning some of that up. > > So, a discussion about which data type to use or support would be worthwhile. > I think the answer lies in analyzing what is being stored as a BLOB and use > the correct Java data type for it. If it's a serialized Object, then use an > Object data type. If it's a byte array that holds the contents of a file, > then use a byte array, etc. I imagine such an analysis would break down in > the Content component - where the Java data type might be unknown. > > I know this doesn't answer your question, I'm just sharing things I've > learned and thoughts I've had on the subject. > > -Adrian
smime.p7s
Description: S/MIME cryptographic signature