rubyhacker / gmail.com wrote:

>Jamey Cribbs wrote:
>  
>
>>>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.
>>    
>>
>
>That's very interesting, because I was assuming total symmetry
>between what I could get out of the database and what I could put in.
>
>I mean, sure, calculated fields are an exception. But I never thought
>of your one-to-many as just another calculated or virtual field.
>
>  
>
<Jamey dons Database Guy hat>

Well, I view it as analogous to doing a join in SQL.  To get the data 
from a one-to-many link in SQL you would normally do a JOIN in your 
SELECT statement.  This gives you a result set with the columns from 
both tables showing up on each record.  The data is now no longer 
normalized, therefore it no longer has the same structure as either of 
the original tables.

That's kind of how I view a #select in KirbyBase that has a one-to-many 
link in it.  I actually like it bettern than a JOIN in SQL because the 
data is still normalized, but I don't look at it as something that you 
could modify and then turn around and update the database with.

<Jamey removes Database Guy hat>

>I guess I thought if I stuck five things in the array and did an
>insert of the parent object, it would make an entry in the parent
>table and five entries in the child table.
>
>  
>
I definitely see your point.  Again, I was basing the one-to-many link 
similarly to how SQL works.  In SQL, you would not do it the way you 
just said.  You would actually do an INSERT on the parent table, then 5 
INSERTS on the child table.

Let me think about what you are saying.  Maybe for the future...

>If you look at Marshal or YAML, everything goes both ways. True,
>there are some things that can't be stored at all. But there is
>never any one-way storage.
>
>If one-to-many links are not symmetrical, that's the best reason
>of all I'll never use them.
>  
>
Well, based on your previous comments about my proposed implementation 
of one-to-many links, I kind of figured you wouldn't be using them 
anytime soon!  :-)

>I still wish others would express opinions. Is anybody else even
>reading
>this thread? If not, we could have this discussion in private. I have a
>
>feeling there might be two or three people on this list as smart as
>both of us put together.
>  
>
I know.  I can't believe others on this list don't find this discussion 
as exciting as I do!  :-)

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.