Hi Thomas, Ron, > Yes, I still think this is the right way to approach this. Stored > procedures vary a lot between DB products. And even with the same > Product they can be used in many different styles. > So I think it's better to provide a clean way to plug in user defined > Stored procedure based extensions than to built something > into the OJB > core which will fit only into a small number of environments.
Not to stir the pot, and I will readily admit that my understanding of JDBC and OJB is still inadequate, but I thought that the java.sql.Statement classes provided a portable way to make these calls and that it was up to the specific JDBC driver to handle the RDBMS-specific stuff. Perhaps extensions to the o.a.o.b.platforms.Platform interface and the related sub-classes that support SP's and/or UDF's? > > With respect to the specific changes you mention, here are my > > explanations: > > > > I had to extend > > org.apache.ojb.broker.accesslayer.StatementsForClassImpl > because this > > was where the JDBC statement is created that will be used to perform > > the insert/update/delete operation. Out of the box, this class > > creates a PreparedStatement. In my situation, I needed it to create > > a CallableStatement so that I could 'harvest' values that were > > returned by the stored procedure. So, my change was to simply > > replicate the code in prepareStatement(Connection, String, boolean) > > and change "con.prepareStatement" to "con.prepareCall". > > Maybe we can avoid this copy/paste reuse by providing some > abstraction > in OJB? IMHO, this is a good compromise, though I really think greater integration for stored procedures should be considered for 2.0. Just my $.02. > > I had to override getStatementsForClass(ClassDescriptor) because the > > implementation provided by > > org.apache.ojb.broker.accesslayer.StatementManager instantiated the > > StatementsForClassImpl class, not my extension (above). > > Maybe this could be made configurable by using our > ConfigurableFactory > concept and a new entry in OJB.properties? Hmm, I'll give it a try and see if I can't hack something out. BTW, that ConfigurableFactory class solved some other non-db-related problems in my design, so thanks! > > I believe that somewhere in my dialogs with Thomas, we discussed the > > possibility of making the first situation 'pluggable' so > that neither > > of these extensions would be required. Maybe some sort of > > 'StatementFactory' implementation. I don't recall exactly where > > those discussions went. Maybe it's time to reconsider the option > > since others are starting to use stored procedures. > > I agree, if there is something that could make the > integration of user > extensions easier we are happy to implement it! Gotta love OSS... ;) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
