Thought inc.

The Dynamic O/R Mapping Company

CocoBase Technical Support Forums
For access to developer site with software download and doc's, please request CocoBase download and password
will be emailed to you. Response to posts will appear when answered by THOUGHT Support team.
NOTE:You must register separately with forum in order to post your questions, please click on register icon below.
Home   Frequently Asked Questions   Search   Edit your profile   Registration is free!  
Email This Page to Someone!
Show a Printable Version
CocoBase Enterprise O/R Forums > CocoBase Bug Reports
Data Retrieval Of Depedent Objects
< Previous Thread     Next Thread >
Thread    Post New Thread     Post A Reply

Registered: May 2001
Posts: 1


I am working with a demo version of CocoBase and followed some of the examples in the tutorials.

I manually created a Customer table and an Employee table. In the Employee table, I created a foreign key that refers back to the Customer table, establishing a 1-M relationship between an Employee and the Customers they had served.

I generated a map of both tables and then automatically generated the Java code using CocoAdmin. [Regular Java objects, not EJB's] CocoAdmin was automatically aware of the foreign key relationship, and generated code in the Employee object that allowed retrieval of relevant Customer objects.

So I tried to use the Employee class to retrieve a list of related Customers. [Employee.getCustomers ()] However, only Customer data/rows that were inserted using the Employee class were retrieved/visible. [i.e. Employee.setCustomer (aCustomer)]. But the Customer data I entered manually in the Customer table were not retrieved/visible. [insert into Customer values ('XXX', 'YYY', etc). I made sure to enter a foreign key that points back to a valid Employee tuple in the Employee table.]

Is this normal behavior? Shouldn't all the relevant data in the Customer tables be retrieved, regardless of whether the data was entered using CocoAdmin generated classes or manually entered in the database? Is there a work-around?

05-19-2001 10:38 PM
Click Here to See the Profile for willh    Find more posts by willh        Edit/Delete Message    Reply w/Quote    IP: Logged

Registered: Apr 2001
Posts: 19

By default the getCustomers would read data from the database
only once. This is because getCustomers would be based on
a null collection that gets populated with values once. If
you did a setCustomers before calling getCustomers you would
circumvent this behavior and basically cause the class to
think the data had already been read from the database. In
fact what might be happening depending on what code was
generated is that you might have 'deleted' all of the related
objects if you called setCustomers because you told the
system to override the related objects with a new list of

Does this sound like what might have happened? If so you
should always call getCustomers first before assuming the
contents to ensure that the whole list of objects is read.
Then you should edit the collection which was read and either
add/insert or delete objects from that collection because it
will likely be used to 'populate' the relationship with the
exact contents of the data.

In otherwords it sounds like it did what you asked it to, but
not what you intended for it to do :)


05-22-2001 03:24 PM
Click Here to See the Profile for admin    Find more posts by admin        Edit/Delete Message    Reply w/Quote    IP: Logged
All times are PST (US)    Post New Thread     Post A Reply
Forum Jump:
< Previous Thread     Next Thread >

Forum Rules:
Who Can Read The Forum? Any registered user or guest.
Who Can Post New Topics? Any registered user.
Who Can Post Replies? Any registered user.
Changes: Messages can be edited by their author. Messages can be deleted by their author.
Posts: HTML code is OFF. Smilies are OFF. vB code is OFF. [IMG] code is OFF.

Admin Options:
Open / Close Thread
Move Thread
Delete Thread
Edit Thread

< Contact Us - THOUGHT Inc. >

Copyright © Jelsoft Enterprises Limited 2000.
Copyright 2001 All Rights Reserved, THOUGHT Inc.