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.

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.

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.

> >
> 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.
>

I think that's very close to my own way of thinking.

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.


Cheers,
Hal