Death to recursion! Re: Child vs parent records

[Ed Kleban]

On 12/11/05 8:34 AM, "Ruslan Zasukhin" <sunshine at public.kherson.ua> wrote:

> On 12/11/05 3:30 PM, "Ed Kleban" <Ed at Kleban.com> wrote:
> 
>> This example ONLY works because in your own mind you assumed that "HaveBorn"
>> (which I would have named "isParentOf") means that when you define the link
>> you will always specify the parents on the left side of the link and the
>> children on the right side of the link.  And because you do this it just so
>> happens that kFromParentToChild and kFromChildToParent work as you intended.
>> 
>> But what if in my mind I choose to implement the "isChildOf" relation
>> instead?  That would put the children on the left and the parents on the
>> right.  In that case kFromParentToChild would not return me what I want or
>> expect.
> 
> I believe (hope) that our docs say:
> 
>     Left table == Parent Table
> 
>     Right table == Child table
> 
>  

Not really.  It is the case in V4RB_Reference_2 for specifically the method:

    CreateForeignKeyLink(
     inName as String,
     inKeyField as VField,
     inPtrField as VField,
     inOnDelete as EVOnDelete = kSetNull,
     inOnUpdate as EVOnUpdate = kCascade,
     inTemporary as Boolean = false ) as VLink

    Parameter:  Description:
    inName   The name of link.
    inKeyField  The PRIMARY KEY field of ONE Table.
    inPtrField  The PTR field in the MANY Table.
    inOnDelete  The behavior on deletion of record-owner.
    inOnUpdate  The behavior on update of record-owner.
    inTemporary  TRUE if link is temprary.
  
That you point out:

    To specify a foreign key link you need to define the following:
    € A name for the link, unique in the scope of the database.
    € The KEY field of the Parent table (ONE table).
    € The PTR field of the Child table (MANY table).
    € The behavior of the link on deletion of a record in the Parent Table.
    € The behavior of the link on update of a KEY field value in the
      Parent Table.

I.e. you associate Parent with ONE and Child with Many.  This makes perfect
sense and I agree with it.

But the terms "Parent" and "Child" are not even used in the description of
CreateBinaryLink.  Nor do I think they need to be or possibly even should
be.

Unlike CreateForeignKeyLink, the CreateBinaryLink command can create 1:1,
1:M, M:1, and M:M relations ships -- as you have frequently pointed out to
me.  In this more generalized definition the concepts of "Parent" and
"Child" are less clear, may be irrelevant, and I would argue only offer an
opportunity for more confusion.

Why should I not be able to implement a "ChildOf" relationship if I so
choose instead of a "ParentOf" relation ship?   If I can use kLeftSide and
kRightSide as arguments to FindLinked it makes it perfectly explicit what I
want in terms of the relationship that I envision in my own head.  It makes
sense and works for 1:1, 1:M, M:1, M:M.  It makes sense and words for TableA
= TableB and TableA <> TableB.   It makes sense if I define my relation ship
as "ParentOf", "ChildOf", "GivesTo", "TakesFrom", or anything else.

And it does not ever result in the confusion you have, nor make any special
fuss about "recursion" that arises when you are faced with trying to figure
out how to use, and make sure you have defined your link correctly for
kFromParentToChild vs kFromChildToParent.

>> Nowhere is this dependency made clear in the documentation.
> 
> Then ops.

Yes, "oops".    

("ops" = an abbreviation for operations)
("oops" = woops, we must have left that out)

>> Nor should it have to be.  If we simply use "Left" and "Right" instead of
>> "Parent" and "Child" then there is never any ambiguity because we use the
>> same
>> terms for access as we used for definition.  And there is no "recursion" mess
>> to have to worry about or explain.
> 
> You mean to rename constants ???
> 
> Still not sure.
>
> We could use also:  kToDown, kToUp  may be
>
 
I mean this:

 If you use the terms "LEFT" and "RIGHT" when you define the table in
CreateBinaryLink, then you should be able to use the terms "LEFT" and
"RIGHT" when you use the link in FindLinked.


If you want to use Parent and Child for the case of 1:M that's fine.
If you want to use kDown and Kup that's fine.

But PLEASE define a syntax that uses the same terms in CreateBinaryLink that
you use in FindLinked.

I happen to think that "Left" and "Right" are good simple terms that make
sense.
 
> IF you will draw records as graph you will get hierachy.
> So term FromParentToChilds means how you want move in hierarchy of objects.

Yes that is true.  And you can talk about this if you want.  It is
interesting.  It may even be useful.

But it is NOT necessary to understand and use FindLinked if you can specify
whether you want to get a VArraySet of LeftLinks vs getting a VArraySet of
RightLinks.

Specifying Left and Right is always clear.  Referring to "Parent" and
"Child" is not clear and offers the opportunity for error if you define your
table wrong and end up using kFromParentToChild backwards.