Ron Gallagher wrote:
Burt --
When I first approached Thomas regarding what I wanted to accomplish, we both agreed that my implementation did not fit well into the 'core' OJB api. However, we agreed to implement some new features and enhance some existing ones to enable me to extend/customize OJB to support my needs. I'm not sure if that view point has changed. Thomas may be able to comment further.
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.
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?
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?
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!
cheers, Thomas
Those are my thoughts.
Ron Gallagher Atlanta, GA [EMAIL PROTECTED]
From: "BURT, RANDALL (CONTRACTOR)" <[EMAIL PROTECTED]> Date: 2003/07/08 Tue AM 10:19:27 EDT To: "OJB Users List" <[EMAIL PROTECTED]> Subject: RE: Where Do Stored Procedures Fit Into An O/R Mapping Layer?
The project I'm on has come to the point of integrating sp's into the app, and I was wondering if there were any plans to incorporate Mr. Gallagher's ideas into the main OJB distribution. If so, I'd be more than willing to lend a hand.
Also, maybe its my ignorance, but could you expand on the modifications you had to make in org.apache.ojb.broker.accesslayer.StatementsForClassImpl and org.apache.ojb.broker.accesslayer.StatementManager.getStatementsForClass(ClassDescriptor)? My (admittedly very limited) understanding of these classes doesn't clue me as to the reason/form of the modifications.
Thanks, BTW, to Mr. Gallagher, Mr. Mahler, and the rest of the OJB team for a great framework and documentation.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
