Persistence Builder is IBM propietary, but this WP can be useful:
http://www7.software.ibm.com/vad.nsf/Data/Document3124?OpenDocument&p=1&BCT=
1&Footer=1
Also:
http://www7.software.ibm.com/vad.nsf/data/document2670?OpenDocument&p=1&BCT=
1&Footer=1
These guys also published in Dr. Dobb's journal a few months ago
about O-R Mapping. Very worth reading.
Regards
Javier Borrajo
www.tid.es
>> I'm trying to rewrite an existing RDBMS based appliaction (client/server)
>> to a 3 tier eJB based app. So, broadly,(*very broadly*) my tables become
>> entity beans and my stored/package procedures become session eJBs.
>> My entity bean called Employee is persisted in the EMPLOYEES table. Later
>> to exploit the OO features of eJBs I will want to extend the entityBean
>> called employee to one called myCompanyEmployee which has, let's say
>> another instance variable called bonus. Consequently, I will have to
>extend
>> the corresponding table EMPLOYEES to MYCOMPANYEMPLOYEES with that one
>> additional column added.
>>
>> This probably falls in the area of OR mapping. The only reason I am
>posting
>> this qustion on this list is to find out how current users of eJB
>> technology are approaching this problem.
>>
>> Is there a design pattern or a technique during the design of eJBs that I
>> can adopt that alleviates some of this Object Relational mismatch. In
>other
>> words, has the eJB technology done anything to minimize the
>> Object-Relational gap? Realizing that eJB isolates the persistence
>> mechanism and so this problem doesn't technically fall under the eJB
spec,
>> I'm fishing for a 'best-practices' kind of answer from some early
adopters
>> and eJB experts who hang around here.
>>
>> Any pointers or docs that can enlighten me on this subject?
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
