Randy Kramer wrote:
> On Monday 12 September 2005 04:11 pm, Jamey Cribbs wrote:
> > >If one-to-many links are not symmetrical, that's the best reason
> > >of all I'll never use them.
>
> There are (some) other people paying (some) attention.
>
> In a traditional relational database system, what goes in can come out, and
> I'm not sure that anyting different is being proposed here (but I may be
> confused).

Traditional relational databases can't return objects, which is
why I'm not thinking solely in terms of traditional relational
databases.

> Aside: One-to-many links are inherently not symmetrical, and I don't know what
> is meant by storing something in the "one-to-many" link.

When you say it in those terms, it does sound nonsensical. That is
why I don't speak in terms of links at all, and why it confuses me
when others do.

I know that one-to-many links are not symmetrical between tables.
What I meant is that their behavior (IMO) should be symmetrical.
If I can select a parent and trigger selects on the child
automagically,
then I should also be able to do an insert on the parent and trigger
child inserts automagically.

> The one to many link is typically accomplished by keys.  If a one to many link
> exists, it is because a record in on table contains a key (to indicate
> linking) to another table wherein multiple records with the same key are
> allowed.  Hence you have a record in one table that relates to (or can relate
> to) multiple records in the other table.
>
> Is there something different going on in KirbyBase?

Yes and no. To me, the essence of what makes KirbyBase cool is:
1. It has a Rubylike interface.
2. It can handle objects (pretty much transparently).

Implementation of point 1 is strong, but that of point 2 is less
strong.


In a nutshell, this is how my thinking has progressed:

1. KB is good at fields with simple types. When I do a select, it
returns
me an object (e.g. a Foobar object) where the field names are simple
accessors. Coolness. Life is good.

2. However, many of my objects are more complex. Say I add a new field
"boss" which is a Person. Hmm. The logical place to store this is in a
table Person (or whatever).

3. So I start to handle it manually. Every time I do a select and get
a Foobar object, I then do a select on the table storing Person
objects.
Then I manually assign the second result to the proper field in the
Foobar object. Likewise, when I create a Foobar object and I want to
insert it, I have to do two manual inserts.

4. No, no. There is enough knowledge in the system that the software
could do this itself. I am doing the computer's job.

5. So I tell Jamey, "I'd like to be able to handle objects that have
attiributes that are not just integers or strings, but objects in
their own right, with their own accessors." And he says, "Oh, you
want one-to-one links." And I say, "Huh? I want what?"

6. And he says, "If we implement one-to-one links, it makes sense
to implement one-to-many." And I say, "Huh??"

7. And I think: What would a one-to-many databasse relationship look
like in object terms? So I decide it must correspond to an array
inside my Foobar object. And it doesn't sound like something I would
ever really use or see a need for. But to accommodate the case that
I might use 3% of the time, the syntax for the case I use 97% of
the time has to become five times nore complex. (Granted, once I
get into it more deeply, I might be glad to have "one-to-many" and
use it in ways I don't foresee now.)

8. But #7 is almost beside the point. Here's an example.

I'm using a,b,c for simple types such as integer or string, and
alpha,beta,gamma for complex types such as Person or whatever.

  Foobar   # Looks like...
    a,b,c  # simple fields
    alpha  # a Barbar object
    beta   # a Bazz object

  Barbar   # Looks like...
    d,e    # simple
    gamma, # Bazz objects
    delta

  Bazz     # Looks like...
    f,g    # simple

Now I have foo = Foobar.new(...) and I want to store foo.

The traditional way would take FIVE insert operations. That is
FIVE user-written lines of code.

My way would take ONE line, ONE insert operation. You store foo,
and in the process it stores alpha, which involves storing d,e, and
gamma, which involves storing f and g.

    footab.insert(foo)

In other words, the recursion is handled for you, rather than your
having to manually recurse. Think of the way YAML handles recursion.
What if every "more complex" data type required a separate dump
call?

Likewise, inserting and selecting should work the same way.

  bar = footab.select { condition_identifying_unique_object }[0]
  # Now bar.alpha.gamma.f is defined (among others)

The other way would take FIVE selects and FIVE assignment statements,
total of TEN lines of user-writtten code.

Here I am replacing fifteen lines with two. In more complex situations,
the difference would be greater.


Hal