Hi Christian, I am also late in my response, this thread feels like a long distance chess match communicating the moves by post (not email that is..) :)...
I understand you implemted a method "public static String asDBParameter(Object value)", but with this solution, one of my questions is: where/when are the conversion-strategies executed? The logical location would be within this method, but then we need more information within this method. We need to know whether there is a strategy configured, so we need to have either the class-desriptor and attribute name, or the field-descriptor. But that is all missing. We do need this because you just cannot convert the java value object to the a string representation, and use this within your query... A java boolean value may need to be converted into an int value on a DB level... String clauses need to be enclosed within quotes, integer values not... So more needs to be done with the java value object... in the following order : - apply conversion strategy - convert to jdbc type - convert to string representation (enclosed with quotes when required) I am missing all this in your solution... Or I do not fully understand your solution... Please explain me where/when in your solution the conversion-strategies are appplied? Where/when are the values converted to the proper JDBC type? Greetings, Roger Janssen iBanx -----Original Message----- From: Christian Lipp [mailto:[EMAIL PROTECTED] Sent: Thursday, April 17, 2008 5:04 PM To: 'OJB Users List' Subject: RE: Is it possible to force OJB not use execute a prepared statement? Hi Roger, sorry for my delay. > As I understand your example, it boils down to the appendParameter > method in your solution. > That method adds the String representation of the value into the query instead of the questionmark, > used as argument placeholder in the prepared statement. Exactly. > In your example you use the asDBParameter method, but that one is not available within 1.0rc5 version of OJB. This should be a static function in your class that overrided SqlSelectStatement (in my example it is DynamicSqlSelectStatement): public static String asDBParameter(Object value) { if (value instanceof Number) return value.toString(); // and so on for all your data types. Don't forgot to quote strings. This is all, you don't need the other things you mentioned. It's just two classes, try it out. You activate the class in your OJB property file with: #----------------------------------------------------------------------- ---- ------------- # SqlGenerator #----------------------------------------------------------------------- ---- ------------- # The SqlGeneratorClass entry defines the SqlGenerator implemementation to be used SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.DynamicSqlSelect Stat ement Regards, CL -----Original Message----- From: Janssen, Roger [mailto:[EMAIL PROTECTED] Sent: Freitag, 04. April 2008 14:05 To: OJB Users List Subject: RE: Is it possible to force OJB not use execute a prepared statement? Hi Christian, It took me a while to have a closer look at your suggested solution, but I finally had some time for it. I do have a few/questions remarks. Maybe some it is caused by using different versions of OJB, I do not know... We use 1.0rc5, but all the things you describe, match this version as far as I can tell. As I understand your example, it boils down to the appendParameter method in your solution. That method adds the String representation of the value into the query instead of the questionmark, used as argument placeholder in the prepared statement. In your example you use the asDBParameter method, but that one is not available within 1.0rc5 version of OJB. However, it seems unlikely to me that this method will do everything that is required. This method has just one argument, a value represented by an instance of a java datatype (integer/date/string/...). What the asDBParameter should do is the following: 1. execute the fieldconversion for the attribute associated with this value, which is given by the fielddescriptor 2. convert the outcome of the fieldconversion into a JDBC typed object instance 3. add the string value representation of the result from step 2 to into the query For step one you require the classdescriptor and the fieldname, or the fielddescriptor. The method asDBParameter does not have access to these objects! They are not passed as arguments. Neither does the encapsulating appendParameter method. So to make this work, these arguments should be passed on, with all these nested method calls, which implies that you have to change a lot of existing OJB method signatures (api interfaces). I am reluctant to do so, because this would really complicate migrating to newer versions of OJB. Step two is not obvious as well. The current OJB solution embeds this conversion inside the PreparedStatement class (used in the StatementManager en Platform-implementation classes), it's like a black box, and you cannot pull the converted argument values out of this statement. So I have no solution yet to perform the conversion. So how are the fieldconversions executed in your suggested solution, and when does the java to jdbc datatype conversion takes place? What also is missing in your solution is that in the end, the StatementManager class (in 1.0rc5) binds all the values to the parameters. This now should no longer be necessary, so you need to implement your own JdbcAccessImpl class that implements a custom public ResultSetAndStatement executeQuery(Query query, ClassDescriptor cld) throws PersistenceBrokerException method. Within this method, the value/parameter binding can be removed (call to method of StatementManager). Not doing this, may not lead to errors, but doing this will remove a lot of now redundant overhead. So... a bit late... but here is my response on your suggested solution and the exaample code you send. Of course... there is always a chance that I got it completely wrong, please let me know. Greetings, Roger Janssen iBanx ************************************************************************* The information contained in this communication is confidential and is intended solely for the use of the individual or entity to whom it is addressed.You should not copy, disclose or distribute this communication without the authority of iBanx bv. iBanx bv is neither liable for the proper and complete transmission of the information has been maintained nor that the communication is free of viruses, interceptions or interference. If you are not the intended recipient of this communication please return the communication to the sender and delete and destroy all copies. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
