«

It sounds interesting to me. Ask Jamey.

Two questions:

1. AR doesn't depend on SQL?
2. Would this allow KB to be a backend db for Rails?


Hal

On 9/12/05, <> wrote:

> Maybe they have cable TV or something.

I've been following this thread with great interest. I just don't have
anything cogent to add that hasn't yet been said.

I use KirbyBase on a few small personal projects where a relational
database would be overkill; not because the data isn't relational (it
is, in one project), but because I'd rather have the data in ASCII
than in a database. On those projects, data portability and
editability is more important than relational...er...relationships.

Jim
--=20
Jim Menard, ,
http://www.io.com/~jimm

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

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.

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?

Randy Kramer

On Sep 12, 2005, at 1:46 PM, wrote:
>>>
>> I know. I can't believe others on this list don't find this
>> discussion
>> as exciting as I do!
>>
>
> Maybe they have cable TV or something.
>
>
> Cheers,
> Hal
>
>
Guys-
I am watching this thread with great interest. I don't have much
to add at the moment but please keep it up.
Cheers-
-Ezra Zygmuntowicz
Yakima Herald-Republic
WebMaster
509-577-7732

On 9/12/05, Jim Menard <> wrote:
> On 9/12/05, <> wrote:
>=20
> > Maybe they have cable TV or something.
>=20
> I've been following this thread with great interest. I just don't have
> anything cogent to add that hasn't yet been said.

Me too.

Michel.

On Sep 12, 2005, at 4:46 PM, wrote:

> It sounds interesting to me. Ask Jamey.
>
> Two questions:
>
> 1. AR doesn't depend on SQL?
> 2. Would this allow KB to be a backend db for Rails?
>
>
> Hal
>
>
>

1. Maybe, maybe not. I get the feeling that it could probably be
adapted with a bit of work. Might have to rewrite a lot of code in
the process

2. Maybe. It would depend on how full-featured the adapter was I
suppose. I was thinking more along the lines of advantages of using
ideas from the ActiveRecord impl. of ORM in KirbyBase, since ORM
seems to be a lot of what you guys are talking about adding to
KirbyBase.

Perhaps I would not even write an activerecord adapter but a
KirbyBase ORM modeled on the activerecord style.

So in conclusion, maybe?

On Monday 12 September 2005 1:36 pm, wrote:

> 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

I have been saving the mails and skimming them, hoping to come back and read
them in depth later. Most of what you are talking about is ORM stuff, and
the KirbyBase query model seems somewhat similar to the Kansas query model,
so if nothing else, I'm hoping to catch sight of something useful to me, even
if I get to everything too late to really participate in the discussion.


Kirk Haines

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

On Monday 12 September 2005 17:06, wrote:
> Randy Kramer wrote:
> 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.)

class moo
def initialize
@1 = Time.now
@2 = Time.now
end
end

moo.new

Moo now contains many Time objects. Throw it at KirbyBase, and you want a one
to many (which just means that one moo contains many time objects). There's
no reason to have multiple Time tables (one for each instance) when they're
the same fields, no? You're right, this would usually fall out of an array,
and it's when you want one to many relationships implemented. This happens a
LOT in the real world (at least in my programming style). Hope this helps
clear up the 3% to 97% analogy.

Logan Capaldo wrote:
>
>
> Perhaps I would not even write an activerecord adapter but a KirbyBase
> ORM modeled on the activerecord style.
>

Perhaps... in fact, that might even be the key to my happiness.

Maybe I'm tying to get Jamey to put stuff *into* KB that should
really be an ORM wrapper *around* it.

Thoughts? Logan, Jamey, others?


Hal