Hi Umesh
I have updated the RelationshipTests [1] to cover your scenario. A Query
that retrieves Departments with no employees, and Employees with no
departments and update their relationship.
I hope this helps with your previous concern about supporting this
scenario...
Please let me know if you have any questions,
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb/src/test/java/org/apache/tuscany/das/rdb/test/RelationshipTests.java
On 4/24/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
Have you tried simulating a full outer join with a union of left and right
joins, like below :
select * from DEPARTMENT left join EMPLOYEE on DEPARTMENT.ID =
EMPLOYEE.DEPARTMENTID UNION
select * from DEPARTMENT right join EMPLOYEE on DEPARTMENT.ID =
EMPLOYEE.DEPARTMENTID WHERE employee.DepartmentID IS NULL
If I understood it correct, this would give you all the necessary data
inside the dataGraph. I quickly tried the query inside the eclipse Database
Explorer connecting with Derby, and the results looked ok, and had the
department with no employees, as well as the employees with no departments.
I'll try to play with this scenario to extend the Relationship testcases
we have, and if I succeed, I'll send a note with my findings later on...
On 4/23/07, Kevin Williams <[EMAIL PROTECTED]> wrote:
>
> I think I did not explain well.
>
> The RDB DAS does not support containment (in the SDO sense)
> relationships
> between business dataobjects in a graph. Since all elements must be
> contained by something, all elements are contained by the (dummy) root
> of
> the graph. So, if you read a department along with its related
> employees
> then the relationship between department and employees is not
> containment.
> Unless I misunderstand, this is what you want.
>
> Here is one way to assign an existing employee to an existing
> department:
>
> // Move an employee to dep1 from dep2
> DataObject emp = (DataObject) dep2.getList("emps").get(0);
> dep1.getList("emps").add(emp);
>
> // Flush changes
> das.applyChanges(root);
>
> If the scenario you have in mind is more complicated than this - like
> if
> you want to add employees that are not part of the existing graph
> - then
> you are looking at merging graphs. There is some early support for this
> but
> not much.
>
> --Kevin
>
>
> On 4/23/07, Umesh Tyagi (utyagi) <[EMAIL PROTECTED]> wrote:
> >
> > But doesn't it pose a big limitation for DAS RDB ? I mean associations
>
> > are not necessarily containment relations. I want to able to assign an
> > existing employee to and existing department or a more intuitive
> example
> > would be relationship between "customer service agent" and "customer".
>
> > How am I ever going to achieve that with DAS RDB?
> >
> > Thanks
> > -Umesh Tyagi
> >
> > -----Original Message-----
> > From: Kevin Williams [mailto: [EMAIL PROTECTED]
> > Sent: Monday, April 23, 2007 3:07 PM
> > To: [email protected]
> > Subject: Re: RDB DAS - How to create non containment association ?
> >
> > On 4/23/07, Umesh Tyagi (utyagi) <[EMAIL PROTECTED]> wrote:
> > >
> > > So whenever I want to associate employees to a department I either
> > > create a new employee or move employee from some other department ?
> >
> >
> > That's right.
> >
> > I am talking about the case when a "employee" object is currently
> > > without any associated department. When we want to assign it to a
> > > department the following query will not include the employee I am
> > > interested in - "select * from DEPARTMENT left outer join EMPLOYEE
> on
> > > DEPARTMENT.ID = EMPLOYEE.DEPARTMENTID "
> > > A right join on the other hand will leave out all the 'departmemt'
> > > objects without any employee.
> > >
> > Thanks
> > > -Umesh Tyagi
> > >
> > >
> > > -----Original Message-----
> > > From: Kevin Williams [mailto: [EMAIL PROTECTED]
> > > Sent: Monday, April 23, 2007 12:43 PM
> > > To: [email protected]
> > > Subject: Re: RDB DAS - How to create non containment association ?
> > >
> > > If you want departments and their related employees then you would
> > > typically use a left join rather than a full join. At least, this
> is
> > > the scenario I see used most often. Our test case:
> > >
> > > RelationshipTests.testRelationshipModification2()
> > >
> > > demonstrates this.
> > >
> > > Thanks,
> > >
> > > --Kevin
> > >
> > >
> > >
> > > To read a set of departments and related employees you would
> typically
> >
> > > use a left outer join rather than a full join since you want
> > >
> > > On 4/21/07, Umesh Tyagi (utyagi) < [EMAIL PROTECTED]> wrote:
> > > >
> > > > How to create non containment association between two existing
> > > > objects
> > > ?
> > > > For example, lets assume the following relationship is a non
> > > > containment association i.e. both objects can exist independently
> of
> >
> > > > each other -
> > > >
> > > > ------------ ----------
> > > > |DEPARTMENT| 1______________* |EMPLOYEE|
> > > > ------------ ----------
> > > >
> > > > Playing with samples code I have noticed that in order to create
> > > > association between two object they need to be part of the same
> data
> >
> > > > graph generated by a single query. So for the following line to
> work
> >
> > > > -
> > > >
> > > > department.getList("employees").add(employee)
> > > >
> > > > both 'department' and 'employee' dataobjects must be under same
> root
> >
> > > > DataObject instance. To achieve this I tried to do a full outer
> join
> >
> > > > between DEPARTMENT and EMPLOYEE but it is not supported by derby
> or
> > > > hsql. The equivalent union result is not typed to DEPARTMENT and
> > > > EMPLOYEE by DAS. The other option is to set the foreign key value
> > > > explicitly in the 'employee' object, but it is not desirable. Any
> > > > other ideas ?
> > > >
> > > > -Umesh Tyagi
> > > >
> > > >
> --------------------------------------------------------------------
> > > > - 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]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
--
Luciano Resende
http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
--
Luciano Resende
http://people.apache.org/~lresende
