Re: Persistence, EJBs and OO-Relational mapping

sriniv79_at_my-deja.com> wrote in message news:918dl9$uqg$1_at_nnrp1.deja.com...
> Thank you for a very illuminating response, Please see my responses in-
> line.
>
> > > First let me state the main issue. What is the rationale behind
 trying
> > > to persist "relational data" in the form of "object oriented data"?
> >
> > Its the other way around. We're trying to persist "object oriented
> > data" by piggybacking off the relational tools.
>
> That might be the right thing to do. But I have seen pure relational
> data, such as Invoice and Line Items, being brought from the RDBMS and
> persisted in object wrappers!! Do you also agree that this is wrong?

Depends. Invoice and Line items may have an OO purpose, i.e., be good objects as well as good records. If you're talking about objects with functionality that is nothing but getters and setters, then the plot thickens:

Purists will howl.

Pragmatic people will look carefully and try and refactor to find the missing functionality and merge it with these objects. Or they'll merge these objects with the "true" functional object.

Those of us using OO-RDBMS wrappers will say that the tool limitations forced us into this situation. For example, I'm using Toplink right now: I have some derived attributes which don't even need to be attributes, but because I need an attribute to map to a column with the Toplink builder I'll put one in anyway. (Note: I can create a "fake" attribute within the builder, but that lasts until I do an import from the latest classes, so this
is useless.)

*Personally*, I see a use for getter/setter objects but I'm in a huge minority.
My ideal model is something like OMT with the Structural, Dynamic, and Functional models separated and working in conjunction. I do see a place for a "pure" Structural model that is wrappered by the Dynamic model. The Dynamic model also uses the Functional model to update the "static" Structural model. Since even Dynamic models have state which has to be converted to (gasp) *data* when persisted, I find this whole purist
behavioral-only-there-is-no-such-thing-as-data idea to be blinkered. Its hardly worth arguing about, because people feel *very* strongly about it, and most disagreements are largely semantic (unimportant) ones.

You will obviously note that I am a pragmatist, although I do actually have a
very strong OO purist streak. Or is that Smalltalk snobbery :-?

So the answer to your question is that I see a need/use for "data objects". However, these are subordinate to and wrappered by the "behavioral objects". If one needs some "intermediate" objects to facilitate the OO-relational map, then so be it.

> > > At the best, the OO paradigm can only implemet the relationships,
 but
> > > may not extend to cover other properties of relational databases
> > > mentioned above. Or am I wrong?
> >
> > The OO paradigm handles all these things but differently, i.e., within
> > its *own* paradigm.
>
> I can only take the *own paradigm* with a pinch of salt. I would like
> my data obey the rules of relational arithmatic whichever paradigm is
> used to represent it.

Then yes, the answer is that OO rules can subsume the relational rules. After all, just write a relational or "Set" interface within the Object class and you have a relational model within OO.

I think its also true that relational rules can subsume the OO ones. Neither "paradigm" trumps the other.

> > > No one has problems with the 3-tier or n-tier application
 architecture
> > > models, then, why are we trying to bring the data layer into
 middleware
> > > tier?
> > Because the OO-Relational bridge has to be made somewhere I guess.
> > What exactly are you refering to here?
>
> Why can't we leave the relational data in the RDBMS layer? Why do we
> need to bring it up a layer higher, and represent tables and relations
> as objects and associations?

If you're going to work in OO, you're going to work with objects and associations. So you have to bring tables and relations "up" to this level. Its just a matter of bridging the "paradigms". Without a bridge, you can't work with both of them together. The point about OO is that we want
to encapsulate this bridge so not all the objects need to worry about tables and relations.

As I said above, you can also make objects and associations look like tables and relations. The relationists need to admit that type inheritance is real, but once they get over this it can happen. (Note to C. J. Date: Integers and Reals are both subtypes of Number :-)

> Why do we need persistent Java components
> that are used to persist the data of relational nature? In other words,
> why do you implement an Invoice as a persistent component?

You want it to be persistent :-?
It would be nice simply to create *any* object instance and say "be persistent".
Are you talking about the idea/fact that in some languages and implementations one has to subclass off
a Persistence class to make the instances persistent? That is just implementation details which identify a "crappiness" or limitation of that particular language or designer. Question: Does this apply to *all* OO languages right now? If so, give it time. This is not a flaw of OO, just the limited state of the art.

> > > Isn't it too simplistic to ignore the power, flexibility and
> > > ubiquity of the RDBMSs?
 

> > Yes. However, OO has its own needs and it cannot seamlessly
> > piggyback these capabilities. One big issue is writing the app
> > with an OO domain but using procedures, since you're splitting
> > the logic between two separate systems. This can be hard to
> > program and harder to manage. Triggers are a bigger problem.
> > If the OO model initiates the change within itself and updates the
> > RDBMS, then how does the rest of the OO model pick up the
> > cascading changes from the trigger within the RDBMS?
>
> The best that Java could offer to search the associated objects is by
> accessing the enumeration of the associated objects and loop through
> them. It lacks the random and conditional access. This violates the
> fundamental qualities of RDBMS tables - projection (select *) and
> materialization (col1+col2).

Aside: If you're focusing on Java, then I must confess I find the language fatally
flawed and detestable. Primitive types, no classes-as-instances, a pathetic collection class hierarchy, no blocks, being unable to add code to a package for a class that was declared in another package to name just a few gripes. Then again, I'm currently making my living off Java, its just that its so inferior :-)

As for your specific issues, relational theory doesn't even recognize cursors -- that is just a "real-world hack". And as for random and conditional access, this could be improved if need be. If you want it, just define a smarter cursor.

> I had the J2EE platform in my mind. I am seeing more and more
> literature, where OO is being suggested as the way to manipulate the
> relational data (e.g. persistent EJBs). I simply can't understand how
> can this be good to any application. That is my basic inquest.

When you see this, you're seeing someone having trouble keeping two paradigms separated. In some sense, persistent OO applications are just a way to manipulate OO "data", so what is the difference? If the relational data is hidden within the OO app, then ignore this literature and just focus on the practical tools they're talking about. If the relational
data is available to query engines, then the point of the app is to do just that, i.e., manipulate the relational data via the (more powerful) OO tools.

 > The
> > data is public for read-only access via SQL, but it has to be private
> > for updating via SQL, because that is in the "backdoor". So the short
> > answer is that OO-Relational mapping is leading us towards better OO
> > applications and that is all.
>
> Do you suggest that the persistent models are useful only in "read-
> only" mode and one must use regular methods like SQL to perfrom the
> updates? I can agree with that to a very large extent.

I'm suggesting the reverse, I think. Obviously, any app needs to use SQL to read/insert/update the data. However, when an OO tool is wrappering RDBMS data and the OO tool is the owner of the data, then other SQL apps can read the data, but they cannot (should not) insert/update/delete the data, because that would bypass the rules of the OO app that could not be located within the RDBMS systems.

Down the road, RDBMSs may grow to handle a wider range of rules and OO may choose to shift its rules to the RDBMS. This will happen long-term, IMHO. The question is: Is RDBMS expanding "up" or is OO expanding "down" :-? DOes it matter?
>
> But, what about the random access requirements of the data, even in the
> read-only mode? I can't JOIN objects like I do tables.
>
That is set-thinking. Relational is set-at-a-time, OO is one-at-a-time. If you want OO using sets, its easy to write this capability. I have relational-
like Table objects in OO which I can join. (I have yet to find a use for it, though.) Its just reimplementing the RDBMS capabilities. OO does sets and items. Relational only does sets and is inefficient for sets of one.

OO would say that there is no such thing as randomly requiring joins between objects. If you really need to join them, you'll have some meaningful behavioral reason and then it'll be a "natural" part of the objects' capability.

> So, is there a case against persistence of relational data in OO
> paradigm?

Yes. Relational data don't exist in OO. Rather, they exist as something else. Either (1) the data is part of the objects' state and hence not an issue -- the object's public interface is strictly OO and the relational mapping is a necessary "evil" that is hidden within the object, or (2) the app needs to share relational data with other apps, so it needs OO wrappers to bridge to this data and provide an OO interface for the remaining app. Both of these are reasonable requirements. The only case against is "is there something better"?

Pardon the fuzzy discussion. We're groping with fuzzy boundaries. Received on Thu Dec 14 2000 - 06:22:49 CET