From: Jamey Cribbs <cribbsj@...>
Date: 2005-09-12T23:26:36+09:00
Subject: Re: KirbyBase

Hal Fulton wrote:

> Jamey Cribbs wrote:
>
>> Hal, I considered this, but, again, putting on my "Database Guy" hat, 
>> I thought, "What if there is more than one table that wants to link 
>> into this table?  And what if this other table wants to use a 
>> different "key field" to perform that link?"
>
>
> Good point. Let's let other people weigh in here.
>
> My gut reaction is: Fine, allow other tables to link via other fields, 
> but
> let me use the default when I need/want to.
>
I think the light bulb came on over my head.  :-)

See my comments near the bottom.

> It's different getting stuff *from* the database. I only deal with the
> objects in the collection, and they do indeed come back as Foobar 
> objects.
>
> But I would never design an object by saying, "I'll give it this field,
> which will normally be a string, and this one, which will normally be
> a KBResultSet."
>
Ok, that makes sense.  But, in essence, when you have a field that is 
really a one-to-many link to another table, all you are really doing is 
just getting stuff *from* the database, because, behind the scenes, all 
KirbyBase is doing is doing a select against that child table.

You will never be *assigning* any value to that one-to-many link, 
because it is just a virtual field.  There will never be a "real" value 
stored in the table for that field.  It is always just going to be a 
virtual field that, when you ask for it's value, goes out and does a 
select against the child table and returns the selected records.

>
> I guess what I would like is a simple notation for the common, simple
> operations; and a complex notation (if necessary) for more complex, rare
> operations.
>
> I don't want to complicate 100% of the notation because 1% of the time
> somebody else is going to need that feature.
>
> I'm still trying to figure out a way to say: "If there's no link type
> specified, it's one-to-one. And if there's no field specified, use the
> key field on the child table."
>
I think I get what you are saying.  If the field definition looks like this:

:manager, :person

I could have KirbyBase *assume* the following:

1.  You want :manager to reference a record (object) in the :person table.
2.  The field in :person that :manager should equal will be the :person 
table's key field (designated in the definition of the :person table).
3.  The data type of :manager will be the same as the data type of the 
key field of the :person table, so go look up that up.

This would be the default behavior.  If the user wanted to override 
KirbyBase's assumptions, they could do that by being more verbose in the 
create_table method.

Jamey

Confidentiality Notice: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. If you are not the intended recipient(s), you are hereby notified that any dissemination, unauthorized review, use, disclosure or distribution of this email and any materials contained in any attachments is prohibited. If you receive this message in error, or are not the intended recipient(s), please immediately notify the sender by email and destroy all copies of the original message, including attachments.