--- On Sun, 9/12/10, Scott Gray <[email protected]> wrote: > On 12/09/2010, at 2:57 AM, Adrian > Crum wrote: > > > --- On Sat, 9/11/10, Scott Gray <[email protected]> > 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's interesting from a historical perspective. But, where do we go from there? What is the ByteBuffer being used for? Can we make the service definition or whatever more specific? In other words, instead of adding ByteBuffer support to JdbcValueHandler, can we be more specific about what we're storing in the BLOB - and use another data type? Maybe ByteBuffer support SHOULD be added to JdbcValueHandler - since there is a theoretical performance advantage. Like I said before - it's worth discussing. Personally, I have no preference. All I know is that the BLOB handling is a bit muddled and it would be nice to get things more clearly defined. That's why I introduced the new data types - in the hope of bringing clarity. -Adrian
