Dan Christopherson wrote:
> OK, I've got comments below trying to explain why your implementation is
> giving you problems. What it amounts to, though, is you're doing more work
> than you really need to and probably making the database do more work than
> it needs to.
>
> First, as a fair warning, there are problems with inheritence in EJBs: you
> don't have polymorphism because to get an object you need to know its
> exact type. The way you're trying to implement it gives you limited
> polymorphism (because you could look up a person corresponding to a
> Teacher and get the 'person' type things) but, casting down will never
> work, and overridden behavior won't work.
>
> You have three options.
> 1. Continue with your current implementation path, but make the
> 'subclasses' purely delegate to their 'superclasses' for their
> implementations of 'inherited' behavior. This is known as the COM model
> for inheritence, except that it's even worse because you'll have N
> database/cache lookups per operation. Yuk.
> 2. Map the derived beans to writable Views in the database, and map
> all inherited fields in all derived beans. Here you're depending on
> functionality that's not available in all databases. This does allow you
> to retain the limited polymorphism that I discuss above.
> 3. Create a complete table beneath each bean and map all inherited fields
> into that bean. I've done this for an application. The main problem here
> is that finding all Actors (including subclasses) that fit a certain
> criteria gets really clumsy and will likely not perform well.
>
> On Wed, 28 Mar 2001, ivanhoe Abrahams wrote:
>
> > Hi all
> >
> > I am busy writing a system which will be using a fair amount of Entity
> > inheritance.
> > I gathered from previous messages that this is possible in JBoss.
> >
> > Here is a short decription of some of my Entities.
> >
> > ACTOR -> SuperClass
> > -----------------
> > REMOTE = Actor extends EJBObject
> > HOME = ActorHome extends EJBHome
> > IMPL = ActorBean extends EntityBean
> > PK = ActorPK
> > // Has a INTEGER Primary key which maps onto the ActorPK
> > // plus what kind of actor (entity acting on the system) this is
> >
> > PERSON -> extends Actor
> > ------------------
> > REMOTE = Person extends Actor
> > HOME = PersonHome extends EJBHome
> > IMPL = PersonBean extends ActorBean
> > PK = NO PK uses ActorPK
> > // Has INTEGER Primary Key which maps onto the ActorPK
> > // plus FirstName, LastName etc....
> >
> > Teacher -> extends Person
> > ------------------
> > REMOTE = Teacher extends Person
> > HOME = TeacherHome extends EJBHome
> > IMPL = TeacherBean extends PersonBean
> > PK = NO PK uses ActorPK
> > // Has INTEGER Primary Key which maps onto the ActorPK
> > // plus whatever further defines a teacher. like subjects he teaches....
> >
> > In each SUBCLASSED entitiy's ejbCreate I lookup the direct superclass's
> > Home and then I create that superclass
> If you lookup the direct superclass's home, you're doing aggregation, not
> inheritence (sort of, but this is one root of the problems).
>
> > .... This recurses right
> > up to the Top level super class which calculates the Primary key value
> > and sets it. As the call returns down to the original calling object's
> > ejbCreate
> > it sets the Primary key value at each subclassed object's level.
> >
> > This all works great.
> >
> > BUT
> >
> > My problem is that on the client side I have a reference to the Teacher
> > Bean . Now I want to set the FirstName (which actually exists on the
> > Person Bean).
> > I can call setFirstName because I inherited Person(REMOTE) AND I can
> > trace the call through to the PersonBean(IMPLEMENTATION) but
> > when I look in the database the value that I set via setFirstName is
> > NOT THERE (only NULL) .
> The way you've implemented this, you'd need to re-implement the
> 'inherited' getters and setters to lookup the corresponding superclass
> bean and delegate the call. This way lies not a lot of sleep 8^})
>
> > PS While I still have the reference to the Teacher Remote interface I
> > make a call to getFirstName which returns the value that I set.
> Yep. It's in the beans member variable, but has no way of getting to the
> database.
>
> >
> > I have tried to create a person directly and that works great. So no
> > ejb-jar / jaws. xml problems.
> >
> > PLEASE HELP
> >
> > Ivanhoe Abrahams
> >
> >
> >
> >
> > _______________________________________________
> > JBoss-user mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-user
> >
>
> --
> Dan Christopherson (danch)
> nVisia Technical Architect (www.nvisia.com)
>
> Opinions expressed are mine and do not neccessarily reflect any
> position or opinion of nVISIA.
>
> ---------------------------------------------------------------------------
> If you're a capitalist and you have the best goods and they're
> free, you don't have to proselytize, you just have to wait.
> -Eben Moglen
>
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
Thnks Dan
I think that out of the three options you describe I will use the first ...
because I dont want to
rely on technology that's only supported on certain databases and because I
really dont feel like
replicating columns in tables of subclassed classes and having to deal with
complex lookups.
Once again THANK YOU
PS. Do you know how EJB 2.0 will impact on this
Ivanhoe Abrahams
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
