Re: KirbyBase

[e-mail] wrote:

>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.
>  
>
I'm getting you.  :-)

Half of my brain is saying, "This is pretty cool!".  The other half of 
my brain is thinking of all of the little special cases that will need 
to be considered.  This would definitely be cool if it wouldn't be a 
nightmare to code or maintain.

It's exactly what you mentioned in your post a couple of days ago how 
different minds think.  I never would have thought of doing this. :-)

Jamey