Hi Thomas,
Thank you for your answer.
Just another question that prevents me to sleeping:
Imagine you have a Person class and an Address class:
class Person {
String firstName
String lastName
Address address
....
class Address {
String zipCode
String city
....
A Person has an Address.
For OJB, to do an association between Person and Address you need a foreign key
attribute in your database. Normally you should put a foreign key in the relationnal
table Person (which contains an addressID). But you can also put a foreign key in the
table Address (which contains an personID)
=> could you tell if these 2 solutions works with OJB and if there are differences
between them to use OJB??
Do you need also this ID in the class Person or Address?
Thank you
Regards
Sylvain
-----Message d'origine-----
De: Thomas Mahler [mailto:[EMAIL PROTECTED]]
Date: mardi, 10. d�cembre 2002 20:19
�: OJB Users List
Objet: Re: Newbie question: associations
Hi Sylvain,
[EMAIL PROTECTED] wrote:
> Hello everybody,
>
> I'm new to this kind of mapping tool and I have a (maybe stupid)
> question:
>
> I have read the Tutorial 3 (Mapping techniques) and I have seen that
> we can create 1:1, 1:n or m:n associations with OJB.
>
> But ,in practice, What's happen when you retrieve a class (a
> relationnal table) which contains an association (for example 1:1)
> with another class (table)? Are the data mapped automatically
> retrieved?
> How do you do that?
It depends! In tutorial3 there is also a section cascading operations
that tells how to configure the exact behaviour.
there are several options possible:
1. fill reference attributes with fully loaded referenced objects
(auto-retrieve="true")
2. fill reference attributes with proxy objects that defer the loading
of the referenced objects until they are accessed in user code.
(auto-retrieve="true" and proxy="true")
3. don't fill reference attributes (auto-retrieve="false"). In this case
the PersistenceBroker can be used to explicitely load a reference
attribute later.
It depends your application scenario which of these options is the best fit.
> And in the case where you store something? I suppose that we could
> store an object in a class (a table) and this object could be mapped
> in another table (with an id)?
The storing process can be configured in the same way! you can use
auto-update="true" to force OJB to store references, and use
auto-update="false" to prevent cascading update or insert operations.
(You can also configure delete operations in the same way.)
cheers,
Thomas
>
> Thank you for any comments Regards Sylvain
>
>
>
> -----Message d'origine----- De: Kevin Viet [mailto:[EMAIL PROTECTED]]
> Date: vendredi, 29. novembre 2002 11:32 �: OJB Users List Cc: Benoit
> Mahe Objet: design 2
>
>
> Hello all
>
> There's something in Ojb that I can understand in updating an
> existing object
>
> For broker API a call to : broker.save(obj); is only necessary to
> update the db.
>
> For ODMG Api there's no such method and updating an object is done by
> using some setXXX() methods between transaction bounds:
>
> tx.begin () tx.lock(customer, WRITE) customer.setName(name); ...
> tx.commit();
>
>
> I want to create an interface on top of OJB layer (for hiding ojb),
> if I use the broker API it's easy to design a method to update an
> object in the repository : public void update(Object object) throws
> DBException; The object in arguments has already been modified by
> application code and then application request that the object have to
> be updated in the repository.
>
> Using the same considerations, things getting harder if I want to use
> the ODMG Api because of the transaction things. In fact the update
> method can't be so generic because of the call of particular model
> setXXX(), I will have to define an update method for every model
> objects and pass the values to be modified to this method
>
> public void udpateCustomer(Customer cust, String firstName, String
> lastName, int age) { tx.begin(); cust.setFirstName(firstName);
> cust.setLastName(lastName); tx.commit(); }
>
> Writing such methods can be painfull but not impossible ...
>
> Anyone got a better idea to simplify my life ... ? Thx
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
