RE: Where Do Stored Procedures Fit Into An O/R Mapping Layer?

["BURT, RANDALL (CONTRACTOR)" <RA...@DFAS.MIL>]

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.

-----Original Message-----
From: Ron Gallagher [mailto:rgallagh@bellsouth.net]
Sent: Thursday, May 08, 2003 8:26 AM
To: ojb-user@db.apache.org
Subject: Re: Where Do Stored Procedures Fit Into An O/R Mapping Layer?


Michael --

> I'd appreciate any and all comments on this question. 
> I've often wondered where stored procedures should fit
> in an object-oriented application.  

Thomas just checked in a how-to document (xdocs/how-to-work-with-stored-procedures.xml) describing the process that I went through to get OJB to utilize stored procedures.

> They're terrific for performance, and they can be a
> great interface between the object and relational
> layers.  Folks who approach problems from a data
> modeling slant are usually enthusiastic about them.
> 
> But I've seen them terribly abused.  The object bigot
> in me worries about diffusing business logic - some in
> objects, some in the database.
> 
> How would one use stored procedures with OJB?  Thank
> you - MOD

On my current project, we're using stored procedures to handle two situations:
1) All CUD (Create, Update, Delete) operations.
2) Any application function that involves a large amount of data retrieval and/or creates a large amount of data.

The first situation is pretty self-explanatory and our implementation is covered in the how-to that was just posted.

We use stored procedures in the second scenario for purely performance reasons.  There are several functions in our app that create new entities based on either existing entities or predefined templates.  In either case, the process requires the retrieval of a significant amount of data and the creation of an even larger amount of data.  While it's possible to do all of this in our java code, it quickly became apparent to us that the transmission of that much data back and forth between the database and client would be a real performance problem.  The solution was to create stored procedures to perform these data-intensive functions.

One thing to be careful of when using stored procedures is that you're basically doing data access operations outside of the "ojb pipeline".  OJB has no knowledge of anything you do through the stored procedure.  If your procedure is creating data, there shouldn't be much of an issue.  If your procedure is changing or deleting existing data, then you may have a problem depending on the caching mechanism that you are using and the various "refersh" settings that are in your repository.

My $.02, 0.0174421 EUR using current exchange rates.

Ron Gallagher
Atlanta, GA
rongallagher@bellsouth.net


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org