Thomas,
Of course you're correct. I'd added foreign key
constraints to all my tables. Once I removed them,
OJB did the INSERT and managed all the keys for me, as
you said. I apologize for missing that subtlety.
Should I also remove foreign key constraints on
many-to-many tables? I've got three of them in this
schema. Will OJB handle those as nicely as the 1:1?
"...I agree, there is a learning curve with OJB. O/R
mapping is not trivial. But it is worth the effort.
Once you mastered the learning curve you will ask
yourself, how could I write database applications
without an O/R tool?..." - I totally agree with this
statement. That's why I'm persisting with OJB, even
if it makes me nervous about my release date.
IMHO, two great benefits of an object/relational
mapping layer are that they force SQL code out of the
business objects and they allow CMP without entity
EJBs. You can write J2EE without an app server; J2EE
and EJB need not be synonymous.
Thank you again for your fine work and timely advice.
Sincerely, MOD
--- Thomas Mahler <[EMAIL PROTECTED]> wrote:
> Hi Michael,
>
> Michael Duffy wrote:
> > I have a newbie question, if you don't mind.
> >
> > Your advanced O/R tutorial shows a 1:1 mapping
> example
> > with Article and ProductGroup classes. You've
> shown
> > the table schemas (in German, but I follow you)
> and
> > the repository_user.xml. All very good, of
> course.
> >
> > The repository XML for Article has a
> productGroupId
> > that points to the ProductGroup key, and an
> instance
> > of ProductGroup that is supposed to be owned by
> the
> > Article.
> >
> > Now if I want to ask the broker to store a brand
> new
> > Article, how do I do it? Is the productGroupId
> > required to be set to an existing before I call
> > broker.store(newArticle)?
>
> Depends on the database. If there is a FK constraint
> then yes.
> But as you can see from the table schema, there are
> no formal FK
> constraints. So, the productGroupId needs not to be
> filled.
>
> > If I want to have a new
> > ProductGroup for my Article, do I have to do this
> as a
> > five-step transaction?
> >
> > 1. Create a new ProductGroup instance
> > 2. Store the new ProductGroup instance
> > 3. Get the latest ProductGroup instances's primary
> key
> > 4. Create a new Article, using the PG primary key
> > 5. Store the new Article
>
> No it's much easier, as OJB takes care of FK
> assigment automatically:
> 1. Create a new Article a
> 2. Create a new ProductGroup instance pg
> 3. call a.setProductGroup(pg)
> 4. store the new Article.
>
> OJB manages the FK assignment for you. If you have
> set
> auto-update="true" on the productGroup
> reference-descriptor then OJB
> will also store the new PG on storing the new
> article!
>
>
> > I'm sure it's my lack of understanding, because
> this
> > feels very difficult. I'm still climbing that OJB
> > learning curve.
>
> I agree, there is a learning curve with OJB. O/R
> mapping is not trivial.
> But it is worth the effort. Once you mastered the
> learning curve you
> will ask yourself, how could I write database
> applications without an
> O/R tool?
>
> cheers,
> Thomas
>
> >
> > Thank you for your work, help, and patience.
> > Sincerely, MOD
> >
> >
> > __
> > Do you Yahoo!?
> > Yahoo! Platinum - Watch CBS' NCAA March Madness,
> live on your desktop!
> > http://platinum.yahoo.com
> >
> >
>
-
> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > For additional commands, e-mail:
> [EMAIL PROTECTED]
> >
> >
>
>
>
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
