SV: O/R mapping

[Magnus Rydin]

Title: SV: O/R mapping

That is, I fully agree that this is important when working with existing tables.

WR

-----Ursprungligt meddelande-----
Fr�n: Magnus Rydin
Skickat: den 23 januari 2001 23:33
Till: Orion-Interest
�mne: SV: O/R mapping

Daniel,
I fully agree with you from your POV.
WR

> -----Ursprungligt meddelande-----
> Fr�n: Daniel Cardin [mailto:[EMAIL PROTECTED]]
> Skickat: den 23 januari 2001 10:50
> Till: Orion-Interest
> �mne: RE: O/R mapping
>
>
> I'm a CMP fanatic too :) But keep in mind some of us have to deal with
> existing models that have been created in the
> "traditionnal" RDBMS fashion. It's good to have control on the way CMP
> will work with Orion.
> 
> We have solved the O-R mapping problem by having a code generator
> generate first-cut beans from the database. Then
> we use a heavily modified version of Rickard �berg's java doclet to
> generate the home interface, the remote interface
> a data structure for quick access to data, the ejb-jar.xml AND
> orion-ejb-jar.xml which allows fine-grained control on
> the tables and attributes used for the mapping through the use of
> javadoc tags.
> For example, all CMP fields are marked with the tag @cmp-field. a
> @cmp-table tag will indicate (through the orion-ejb-jar.xml file)
> what underlying table is needed for the bean. Similarly @cmp-attribute
> indicates the doclet what underlying attribute we are
> mapping to. 1-N and N-M relationships are also supported
> through doclet
> tags.
> 
> This allows a quick regeneration of all source files from one master
> bean source file. It also enables, through modifications to the
> doclet, generating other vendor specific files like jboss.xml,
> inprise-ejb.xml etc.
> 
> As a bonus, the doclet generates a fa�ade object that allows
> a connected
> (via remote methods) or disconnected
> (via the data object) view of an entity's data.
> 
> This was a little off-topic, but the point I'm trying to make is that
> when existing schemas are used, some knowledge on the
> mapping process can help.
> 
> Cheers
>
> -----Message d'origine-----
> De : Magnus Rydin [mailto:[EMAIL PROTECTED]]
> Envoy� : 23 janvier, 2001 08:51
> � : Orion-Interest
> Objet : SV: O/R mapping
>
>
>
> One of the things I like best with EJB is that I dont have to
> care about
> how my objects are stored (Yes, im a CMP fanatic).
>
> So my personal contribution to the subject must be:
> who cares how many tables are used 'back there' ? :)
>
> > -----Ursprungligt meddelande-----
> > Fr�n: Daniel Cardin [ mailto:[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]> ]
> > Skickat: den 23 januari 2001 05:01
> > Till: Orion-Interest
> > �mne: RE: O/R mapping
> >
> >
> > I'd like to point out that a third table is only needed for a N-M
> > (many-to-many) relationship.
> > In the case of a 1-N relationship, simply have a foreign key to the
> > master table.
> >
> > For example :
> >
> > Customer object refers to a Country object
> > you a Customer will only have one Country object. you do NOT need a
> > third table to map this.
> > Simply add a field in Customer that contains the foreign key to the
> > Country object.
> >
> > The EJB 2.0 mapping is Simple
> >
> >
> >
> > Customer ...
> >
> > public abstract Country getCountry();
> > public abstract void setCountry(Country aCountry);
> >
> > and in Country
> >
> > public abstract Collection getCustomers();
> > public abstract void setCustomer(Collection customers);
> >
> > This is fully supported by Orion, which will populate the
> collection
> > object automatically.
> >
> > Cheers,
> >
> > Daniel
> >
> >
> > -----Message d'origine-----
> > De : Tony J Brooks [ mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ]
> > Envoy� : 22 janvier, 2001 11:27
> > � : Orion-Interest
> > Objet : RE: O/R mapping
> >
> >
> >
> > Hi Theis,
> >
> > As much as I can remember, there *is* - definitely - a need for an
> > intermediate third table to contain the mapping
> information.  By using
>
> > this
> > third table, you eliminate data replication/redundancy in the
> > other two
> > tables.
> >
> > To my knowledge this is a common technique.  ER tools
> typically create
>
> > such
> > an intermediate table for you when you select a relationship to be
> > 'zero/one/many to many'.  Whether you see that on your diagram is
> > another
> > matter, but you will definitely see it in your DB ;)
> >
> > Apologies if I have misunderstood your question.
> >
> > Bye for now,
> > Tony.
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [ mailto:[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]> ]On Behalf Of
> > [EMAIL PROTECTED]
> > Sent: 22 January 2001 15:10
> > To: Orion-Interest
> > Subject: O/R mapping
> >
> >
> > Hi!
> >
> > I have been reading the complex-or example and ploughed
> > through the atm
> > example. In the complex-or example it is stated that
> collections are
> > mapped
> > to an another table and that the reason for this is
> normalization. The
>
> > Atm
> > example is also following this principle.
> >
> > Is this really correct? I have never seen the necessity for mapping
> > anone
> > to many relation to a third table (even though it was a long
> > time ago I
> > read the rules of normalization I'm very doubtful that this
> > is correct).
> > Could someone tell me the rational behind this.
> >
> > If this not true, how does the xml look like (in the
> > orion-ejb-jar.xml)
> > when you only map the relation as a foreign key?
> >
> > Regards
> >
> > /Theis
> >
> >
> >
> >
>
>