On Wed, 2004-10-06 at 17:30, Armin Waibel wrote:
> Hi Martin,
>
> > If I get an A object (always through ODMG) from the DB, change the field
> > A.b_id to another valid B id and try to persist, this fails.... or
> > worse, it does not have any effect. Am i forced to get the B object and
> > perform an A.set(B) or is there any better way to do this knowing the
> > id? (I am trying to avoid querying B again)
>
> The referenced object B is dominating the FK field b_id in A. This mean
> if A has no B reference OJB assume that the reference was deleted and
> set b_id to null. If you lookup A and B was materialized too
> (auto-retrieve is true in reference-descriptor in A) and then change
> b_id, OJB get the referenced B and override the changed b_id with the
> old value.
> So you have to load the new B object and replace the referenced object in A.
>
> regards,
> Armin
>
Ok... I tried to do what you said (more or less) but I still have
problems. I'm going to tell you the scenario that will help for sure. I
get the A object, change the references (not the embedded objects but
the Integer objects which map the FK), then I pass this object and the
transaction to an update method. In that method using Metadata I guess
which references this object has (*) then I read the new referenced
objects, load them in the main object and persist... nothing happens!
The interesting point is that if i clone the main object (inside the
update method), inspect clone's references using Metadata, load new
referenced objects into the clone and finally I copy clone data into the
original object: it works perfect. Now i am lost! :)
I post the code just in case.
(*) I do this because this method has to be generic in order to use it
with many objects which are subclasses of the main class
(BaseBusinessObject).
public final void updateBOtx(BaseBusinessObject bbo,TransactionExt tx)
throws ComputersServiceImplException,CloneNotSupportedException
{
/*notice that if the lines begining with // are uncommented an the
lines ending in // are commented everything works, if the code is left
just like it is now... it has no effect.*/
Class boClass;
MetadataManager mm;
DescriptorRepository dr;
ClassDescriptor cld;
String tableName;
Vector references;
//BaseBusinessObject bboClone;
//bboClone=bbo.cloneIt();
try
{
logger.debug("Triggering object update");
if(!tx.isOpen())
{
logger.debug("Opening transaction...");
tx = (TransactionExt) odmg.newTransaction();
tx.begin();
}
//boClass=bboClone.getClass();
boClass=bbo.getClass();//
mm = MetadataManager.getInstance();
dr = mm.copyOfGlobalRepository();
cld = dr.getDescriptorFor(boClass);
//tableName = cld.getFullTableName();
references = cld.getObjectReferenceDescriptors();
for (int i = 0; i < references.size(); i++)
{
Class referencedClass;
BaseBusinessObject referencedObject;
String id;
ObjectReferenceDescriptor reference;
reference = (ObjectReferenceDescriptor)
references.get(i);
referencedClass=reference.getItemClass();
//id=BeanUtils.getProperty((Object)bboClone,(String)reference.getForeignKeyFields().firstElement());
id=BeanUtils.getProperty((Object)bbo,(String)reference.getForeignKeyFields().firstElement());//
logger.debug("Reference found! -
"+(String)reference.getForeignKeyFields().firstElement()+"="+id+"
class="+referencedClass.getName());
referencedObject=getBOtx(referencedClass,id,tx);
//BeanUtils.setProperty(bboClone,reference.getAttributeName(),referencedObject);
BeanUtils.setProperty(bbo,reference.getAttributeName(),referencedObject);
}
//bbo.copy(bboClone);
tx.lock(bbo,Transaction.WRITE);
logger.debug("Transaction checkpoint...");
tx.checkpoint();
}
catch (Exception ex)
{
tx.abort();
throw new ComputersServiceImplException("Exception thrown
while updating BO in ComputerServiceImpl.updateBO()",ex.getCause());
}
}
>
> Martin I. Levi wrote:
>
> > Hi Armin,
> >
> > Well I figured out what happens. In the rc5 application (which was made
> > some time ago) the repository-settings were:
> >
> > auto-update=false
> > auto-delete=false
> > auto-retrieve=true
> >
> > (just like in the rc7 application) but the big difference is that in the
> > r5 application when i changed a 1:1 reference my program cared to look
> > for the new referenced object and load it "inside" the main object and
> > then call ODMG to persist the updated object. This task was not done
> > automatically. What i wonder is if this could be done automatically. I
> > don't know if i am clear enough... I will try an example.
> >
> > Lets suppose I have an A class and a B class:
> >
> > class A
> > {
> > Integer id;
> > Integer b_id;
> > B b;
> > //more fields
> > //getters and setters for id, b_id, b and other fields
> > }
> >
> > class B
> > {
> > Integer id;
> > //more fields
> > //getters and setters for id and other fields
> > }
> >
> > In sql terms: A and B are mapped to different tables. In the table
> > associated to A one column (mapped to b_id) is a FK to the table
> > associated to B. And id is the mapping of the PK of each table.
> >
> >
> > If I get an A object (always through ODMG) from the DB, change the field
> > A.b_id to another valid B id and try to persist, this fails.... or
> > worse, it does not have any effect. Am i forced to get the B object and
> > perform an A.set(B) or is there any better way to do this knowing the
> > id? (I am trying to avoid querying B again)
> >
> >
> > On Mon, 2004-10-04 at 17:13, Armin Waibel wrote:
> >
> >>Hi Martin,
> >>
> >>Martin I. Levi wrote:
> >>
> >>>Well, I have an application on rc5 where everything works well and
> >>>another application on rc7 which is giving me problems. When I update
> >>>(through ODMG) an object with 1:1 references, the changes on these are
> >>>not updated.
> >>>Im comparing both applications to find out what happens but I still dont
> >>>know.
> >>>
> >>
> >>difficult to guess what's going wrong. Fixed some spots in ODMG
> >>implementation which could be responsible for this behavior.
> >>Please try the latest from CVS OJB_1_0_RELEASE branch (next maintenance
> >>release is coming soon)
> >>or see
> >>http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=8991
> >>to fix your version manually.
> >>
> >>If this doesn't solve your problem, please try to write a test case or
> >>modify an existing one to show the issue.
> >>
> >>regards,
> >>Armin
> >>
> >>
> >>>On Wed, 2004-09-29 at 15:20, Robert r. Sanders wrote:
> >>>
> >>>
> >>>>As I understand it both the OTM and ODMG implementations do this
> >>>>internally, so you must turn it off at the persistance-broker level. I
> >>>>have tried OTM (I don't particularly care for the ODMG API) but as I
> >>>>want to use the Spring framework I decided to stick w/ the
> >>>>PersistanceBroker for now.
> >>>>
> >>>>Martin I. Levi wrote:
> >>>>
> >>>>
> >>>>
> >>>>>Hi Armin,
> >>>>>
> >>>>>I see in the documentation that I cannot use auto-update=true with ODMG.
> >>>>>
> >>>>>Is there any way to get OJB working this way:
> >>>>>
> >>>>>auto-retrieve=true
> >>>>>auto-update=true
> >>>>>auto-delete=false
> >>>>>
> >>>>>through OTM ? suggestions are welcome!
> >>>>>
> >>>>>
> >>>>>On Mon, 2004-09-27 at 18:24, Armin Waibel wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Hi Martin,
> >>>>>>
> >>>>>>about repository.dtd
> >>>>>>http://db.apache.org/ojb/docu/guides/repository.html
> >>>>>>
> >>>>>>
> >>>>>>the auto-xxx settings
> >>>>>>http://db.apache.org/ojb/docu/guides/basic-technique.html#Setting+Load%2C+Update%2C+and+Delete+Cascading
> >>>>>>
> >>>>>>and as sub-section in 1:1, 1:n .... section, e.g.
> >>>>>>http://db.apache.org/ojb/docu/guides/basic-technique.html#1%3A1+auto-xxx+setting
> >>>>>>
> >>>>>>
> >>>>>>regards,
> >>>>>>Armin
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>---------------------------------------------------------------------
> >>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]
--
Saludos,
Martin I. Levi
Centre Tecnol�gic de Transferenci�ncia de Calor
Universitat Polit�cnica de Catalunya
www.cttc.upc.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
