KirbyBase

[Kevin_Brown]

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.

···

On Monday 12 September 2005 17:06, rubyhacker@gmail.com 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.)

[HAL_9000]

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

[Jamey_Cribbs1 (Jamey Cribbs)]

rubyhacker@gmail.com wrote:

Randy Kramer 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

···

On Monday 12 September 2005 04:11 pm, Jamey Cribbs wrote:

[James_Britt4 (James Britt)]

Jamey Cribbs wrote:

···

rubyhacker@gmail.com wrote:

SQL is a standard, but to me it's old technology. It was trendy and
cool in the 60s, but then so was the beehive hairdo.

You know, beehive hairdos are greatly under-rated. Remember how many pencils the principal's secretary was able to store in her hair in "Ferris Bueller's Day Off"?

Plus now I have "Rock Lobster" running through my head.

James

--

http://www.ruby-doc.org - The Ruby Documentation Site
http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys

[Mark_Probert]

Hi ..

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.

<Putting my Db hat on>
I am not sure that this quite right, and I am very happy to be corrected
here.

Hal, I think that you are talking, database-wise, about two different
aspects of relational database technology. The first select refers to
views, the second to triggers. So, assuming the tables foo and bar
(random SQL syntax ;-))

  table foo (
    id autoinc not null primary_key,
    name varchar(60),
  );

  table bar (
    id autoinc not null primary key,
    name varchar(60),
    value integer,
    foo_id integer,
    FOREIGN KEY (foo_id) REFERENCES foo(id)
  );

Then we can create a view that selects automatically all the bars
associated with a foo (1-to-many) by

  create view foo-bar (Owner, Name, Value) as
    select foo.name, bar.name, bar.value
    from foo, bar
    where bar.foo_id = foo.id ;

So, the referential integrity is built-in using the foreign key
constraint. This is not supported by all the major databases yet
(MySQL, for example, is supporting this in their next major release, I
believe).

Triggers are the next level of constraint and are usually defined on
insert, update or delete operations on tables. So, for example, you
increment a counter on insert or make sure that all the child records
are removed on deletion. So, for the example above, if we delete a foo
record, then all the bar records that refer to the deleted foo_id would
also be deleted.

So, triggers are usually a one-way street. I am not sure that you would
be able to logically create an insert trigger on a child record unless
all the data in the child record could be derived from the parent, or
other tables within the database. If this were the case, then it is
arguable that you even need to have that child record (unless it is a
pure housekeeping record, like a users login attempts, or that kind of
thing).

I hope that clears the waters a little

Regards,

-mark.

···

On Tue, 2005-09-13 at 08:06 +0900, rubyhacker@gmail.com wrote:

[Jamey_Cribbs1 (Jamey Cribbs)]

Hal Fulton wrote:

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?

Hmmm, I don't know. I know that my tendency is to continue to think in traditional "relational DBMS" terms and then Hal throws out some idea that seems crazy at first and then, after a while, starts to make sense.

On the other hand, I don't want to over-engineer KirbyBase so that it collapses under it's own weight. So far, my criteria for deciding what goes into KirbyBase has been pretty rudimentary. Usually I will start to code a new feature, sometimes even getting to the point where it's working. Then I sit on it a little while and if it feels like the new code just doesn't "feel" like it belongs, I usually take it out.

Pretty scientific, huh?

Jamey

[James_Edward_Gray_II]

I'm just watching this thread with interest and I've never even downloaded KirbyBase (though it does look interesting to me). In short, feel free to completely ignore me here.

That said, KirbyBase is really just a programatic persistence tool, the way *I* see it. If we were talking about an industrial strength DB, that would be one thing, but as it is *I* would be all for as many of Hal's programmer niceties as I could reasonably squeeze in. Heck "...the mini-DB with a built-in ORM layer!" would likely become something I would feel compelled to brag about.

I too am a programmer guy though, not a DB guy.

James Edward Gray II

···

On Sep 12, 2005, at 6:51 PM, Hal Fulton wrote:

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_9000]

James Britt wrote:

Jamey Cribbs wrote:

SQL is a standard, but to me it's old technology. It was trendy and
cool in the 60s, but then so was the beehive hairdo.

You know, beehive hairdos are greatly under-rated. Remember how many pencils the principal's secretary was able to store in her hair in "Ferris Bueller's Day Off"?

Plus now I have "Rock Lobster" running through my head.

Thank you. Now so do I.

Hal

···

rubyhacker@gmail.com wrote:

[HAL_9000]

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

I had to spend an hour or so thinking about this (read: napping) but now I
think this reveals a flaw in my thinking.

In this actual case, a DateTime would be stored as a "simple" type. And I
don't think @1 and @2 are valid names. But that is all beside the point.

Suppose someone had two bosses (heaven forbid), boss1 and boss2. Then I suppose
there would be a one-to-many relationship as you say.

And yet, no. I retract that. There would be *two* one-to-one relationships. You
could store a separate key for each. You only have a one-to-many when you use
the same field to look up a variety of child records, correct? Resulting in,
essentially, an array of rows?

Hal

···

On Monday 12 September 2005 17:06, rubyhacker@gmail.com wrote:

[HAL_9000]

Mark Probert wrote:

Hi ..

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.

<Putting my Db hat on>
I am not sure that this quite right, and I am very happy to be corrected
here.

Hal, I think that you are talking, database-wise, about two different
aspects of relational database technology. The first select refers to
views, the second to triggers.

[snip excellent db discourse]

My fault, I accidentally used a database term.

But I wasn't using it in the database sense, but in the ordinary
sense of "causing" or "resulting in." Should have realized what
I was saying and that it would cause confusion.

But I think it was said well a few posts ago: I am wishing that
KB had its own built-in ORM. At least, I think that's accurate.

Hal

···

On Tue, 2005-09-13 at 08:06 +0900, rubyhacker@gmail.com wrote:

[Ezra_Zygmuntowicz3 (Ezra Zygmuntowicz)]

What if you were to store an array of keys in the 'relationshipkey' field that specifies the relationships(separate from the primary key). Then your one to many relationship could actually be a one to one from an element in the array to the child in the other table.

                                          Person has_many Bosses

···

On Sep 12, 2005, at 7:53 PM, Hal Fulton wrote:

Kevin Brown wrote:

On Monday 12 September 2005 17:06, rubyhacker@gmail.com 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.

I had to spend an hour or so thinking about this (read: napping) but now I
think this reveals a flaw in my thinking.

In this actual case, a DateTime would be stored as a "simple" type. And I
don't think @1 and @2 are valid names. But that is all beside the point.

Suppose someone had two bosses (heaven forbid), boss1 and boss2. Then I suppose
there would be a one-to-many relationship as you say.

And yet, no. I retract that. There would be *two* one-to-one relationships. You
could store a separate key for each. You only have a one-to-many when you use
the same field to look up a variety of child records, correct? Resulting in,
essentially, an array of rows?

Hal

-------------------------------------------------------------- ------------------------------
primarykey | foo | bar | baz | relationshipkeys

                            > key | name | foo | bar |

-------------------------------------------------------------- ------------------------------

      1 | str | int | baz |

[1,2,3] | | 1 | bob | bar | foo |
-------------------------------------------------------------- ------------------------------

      2 | str2 | int2 | qux | [4,5,6] > 2 | jon | qux | oof |

------------------------------------------------------------- -------------------------------
                                                                                                                  > 3 | ned | bar | foo |
                                                                                                                   ------------- etc..------------

You've probably already thought of something like this. And I'm not sure how you would make it 'invisible' when pulling and pushing objects from/to the db, but it a thought...

I would love to have a kirbybase/ORM fully in ruby.

-Ezra Zygmuntowicz
WebMaster
Yakima Herald-Republic Newspaper
ezra@yakima-herald.com
509-577-7732

[Randy_Kramer]

A few things:
   * (aside) the attribution above is a little misleading (not if you read it
carefully, though)--I did not write what is in the item 7
   * my background is more in relational database systems than, for example,
in objects in any way shape or form--my earlier answers were purely from the
viewpoint of a "traditional" relational database (hence I feel like I'm in
over my head and should try to bow out gracefully but quickly (And, I'm
not an expert in relational databases, just struggled with them a few times,
in the "good old days".

   * re the last paragraph above, yes, (in a vacuum) you could look at the two
situations above as either a one-to-many relation or two one-to-one
relations, but unless there is some mitigating circumstance (which I won't
try to imagine atm), in a relational database "world" (i.e., by relational
database practitioners, it is a one-to-many). I won't try very hard to
explain why, but I'll throw out words like normalization (generally, getting
the database in a form that minimizes the duplication of information) and ask
one (hopefully leading question):

Consider your example of "someone" having two bosses. What you suggest (to
treat that as two one-to-one relations) is to have two boss fields in the
"someone" record--one pointing to boss1, one pointing to boss2. So, what do
you do when you encounter someone else with 3 bosses? In your scenario (and
a relational data base world, you'd have to modify the "someone" table to add
an additional column for the third boss. In a normalized relational
database, you'd just add another boss record to the boss table pointed to by
the same key that points to that someone's first and second boss.

   * Now, not knowing anything (?) about object databases (is that what
KirbyBase is trying to be) (and not all that much about objects) my
impression is that object databases are not nearly as structured as a
relational database, in fact as someone else mentioned (iirc), they are
almost more of a persistence mechanism so that when you restart an
application after a shutdown, you can recover data that might have been
captured in prior "runnings" of that program. My impression is that there is
(can be) a pretty ragged mixture of objects of all shapes and sizes.

(The object database / persistence mechanism that I have the most knowledge /
experience with is the one in Instiki (is that Madeleine) and that only based
on a short experience with installing and using a local Instiki.)

I guess I'd think two things: I'd like anything that billed itself as an
object database to be able to handle any object (no matter how convoluted,
more below) with something like one save command (and later, one load
command).

By convoluted, I'm trying to remember (without looking back) how you defined
the objects you used as examples. Seems there was one "main" object that
included some sub-objects. (ATM, I don't have any feel for the right
vocabulary (its not "inheritance" iiuc) to describe that situation, nor do I
know whether objects can have sub-objects (I know objects can have attributes
and methods, but I never thought in terms of sub-objects), but, if that is
possible, I would hope for an object data base that could handle such an
object in "all its glory" (ie., with its subobjects) as simply as possible
(one command to save, one command to load).

On the other hand, I can imagine simplified object databases with limited
scope for various reasons (reduced complexity, whatever), that would not
undertake to handle such complex objects but instead require that the various
subobjects be stored separately.

So, I can see that going either way depending on the aims of KirbyBase. (And,
of couse, nobody needs my blessing/permission/agreement to implement whatever
they want.

Hope something here helps, or I've not made to much noise.

regards,
Randy Kramer

I can

···

On Monday 12 September 2005 10:53 pm, Hal Fulton wrote:

Kevin Brown wrote:
> On Monday 12 September 2005 17:06, rubyhacker@gmail.com wrote:
>>Randy Kramer wrote:
>>7. And I think: What would a one-to-many databasse relationship look

And yet, no. I retract that. There would be *two* one-to-one relationships.
You could store a separate key for each. You only have a one-to-many when
you use the same field to look up a variety of child records, correct?
Resulting in, essentially, an array of rows?

[Randy_Kramer]

Maybe not, but you are not the only one that works that way (at least
sometimes)--I usually hope that I don't write much code before deciding to
take something out. (But maybe that's an advantage of Ruby, I guess (for
others more experienced than me), writing some code is sometimes not all that
much work.

regards,
Randy Kramer

···

On Monday 12 September 2005 10:24 pm, Jamey Cribbs wrote:

On the other hand, I don't want to over-engineer KirbyBase so that it
collapses under it's own weight. So far, my criteria for deciding what
goes into KirbyBase has been pretty rudimentary. Usually I will start
to code a new feature, sometimes even getting to the point where it's
working. Then I sit on it a little while and if it feels like the new
code just doesn't "feel" like it belongs, I usually take it out.

Pretty scientific, huh?

[Kevin_Brown]

In relational database design you DO store a seperate key for each. The
one to many relationship (again, in traditional DB design which doesn't have
much bearing on this anyway) simply means that one item can 'contain'
multiple items.

Say for instance that we had an account that could have notes associated with
it. These could be stored in an array or seperate variables (as it really
doesn't matter, it's just how you group the data.) In traditional db design
you'd have one account entry in an account table with id say 29 for example.
You then have two notes entries, each with 29 in their foreign key field to
person. Then, if you go to get notes for account 29 you grab all notes where
their foreign key to person == 29. This is a one to many relationship
because one account 'contains' multiple notes.

So the minute logical difference we're arguing here is whether you should have
two links, Person => Note for the first one, and Person => Note for the
second, or one link that says Person => [Note, Note]. So, in my opinion, you
do have a one to many, not two one to one relationships, however, in code, I
suppose you could implement separate links and then count all the links (read
slow) to fake one to many.

Hope I'm clearer this time.

···

On Monday 12 September 2005 22:10, Ezra Zygmuntowicz wrote:

On Sep 12, 2005, at 7:53 PM, Hal Fulton wrote:
> Kevin Brown wrote:
>> On Monday 12 September 2005 17:06, rubyhacker@gmail.com 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.
>
> I had to spend an hour or so thinking about this (read: napping)
> but now I
> think this reveals a flaw in my thinking.
>
> In this actual case, a DateTime would be stored as a "simple" type.
> And I
> don't think @1 and @2 are valid names. But that is all beside
> the point.
>
> Suppose someone had two bosses (heaven forbid), boss1 and boss2.
> Then I suppose
> there would be a one-to-many relationship as you say.
>
> And yet, no. I retract that. There would be *two* one-to-one
> relationships. You
> could store a separate key for each. You only have a one-to-many
> when you use
> the same field to look up a variety of child records, correct?
> Resulting in,
> essentially, an array of rows?

[CRIBBSJ]

Randy Kramer wrote:

  * Now, not knowing anything (?) about object databases (is that what KirbyBase is trying to be) (and not all that much about objects) my

Randy, that is an excellent question.

This may explain some of the debate that has been going on here (as well as the debate in my head).

I think I first wrote KirbyBase with sqlite in mind. Except, I wanted to be able to use Ruby expressions to "express" my select query rather than have to use SQL. To me, that and the fact that tables were just plain-text files that could be edited by hand, were the two compelling reasons to use KirbyBase.

Hal then came up with the bright idea to have query results be an array of custom class objects, if the user so desired. It was an excellent idea.

Next, Hal made the request to be able to "embed an object within another object", which, in DB guy terms meant, to me, allow for one-to-one links (I threw in one-to-many links as a bonus). See, I think I have always been thinking of KirbyBase as a simple alternative to sqlite with Ruby expression syntax, some relational capabilities, and the ability to return objects instead of just records.

Hal has been looking at KirbyBase as more of an object database/object repository (I have to be careful here because my knowledge of object oriented dbms and ORM is pretty sketchy. I'm probably not using terms correctly).

This helps me to more fully see the disconnect. Where I think it is perfectly normal to have the result set of the "many" side of a one-to-many link be a KBResultSet holding a bunch of records, Hal is expecting it to be more "integrated" into the parent object so it only seems natural for him to be able to turn around and insert the parent object back into the table and have KirbyBase automagically insert the child objects into the child table. This is something as a "relational db guy", I would never think to do, something that actually makes me a little uncomfortable to think about. All of the little extenuating circumstances come to mind like, what if Hal is doing an "update" on the parent object instead of an insert, and what if, in this update, he has added some new child objects to go along with the ones that already exist in the embedded array of children. How do I handle the update on the child table? How do I know which child objects are new and need to be inserted, versus which child objects already exist and just need to be updated. Stuff like that runs through my head and makes me start to sweat.

I mean, I know that it can be done, but it is starting to look like some very complex coding to make sure like it all works right, and being a relational-db-guy, I'm asking myself, "Is it worth it?".

I mean, if I have a parent table called Orders and this table holds customer orders and I have a child table called Items and this table holds the detail items for each Order record, having a one-to-many link that I can use in a select statement to select an order and all of its related detail items in one fell swoop, well that makes a lot of sense to me. It is the kind of select query I have done a million times in SQL. To me, it's even better than SQL because, instead of getting back a denormalized result set that has all of the Order fields duplicated in every record of the result set, KirbyBase will give me back a result set containing the one Orders record and within the Orders.items field of that one record will be a reference to *another* result set holding all of the detail Items records that belong to that Order.

Then Hal comes along and says, "Hold on, buddy. I want to be able to add a new Order object, embed an array of new detail Item objects in that Order object and, performing a single #insert, have KirbyBase add that Order object to the Order table and also add all of those Item objects to the Items table." And I think, "What?! Why wouldn't you just do an #insert to insert the Order record and then, for each of the detail order items, do an #insert on the Items table?" And Hal says, "Because if I can automagically get the detail Items when I do a #select on Orders, then I should be able to automagically insert the detail items when I do an #insert on Orders.".

And, without knowing that much about ORM or object databases, I am guessing that this is what they allow you to do. This is how I think that KirbyBase has started to slide down that slippery slope from "psuedo-relational, sqlite alternative" to object database (or whatever term is correct here).

I'm not saying what Hal is asking for is wrong at all. I just never thought of KirbyBase in those terms and I don't know if that is the direction I want to take KirbyBase. Or do I want to just keep KirbyBase as (hopefully) a small, tight, well-performing, pure-Ruby DBMS that uses Ruby syntax, has some relational capabilities and stores its data in plain-text files.

So, I can see that going either way depending on the aims of KirbyBase. (And, of couse, nobody needs my blessing/permission/agreement to implement whatever they want.

Hope something here helps, or I've not made to much noise.

It has helped me to clarify in my head the question, "What do I want KirbyBase to be?". Now if I only knew the answer.

Thanks, Randy.

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.

[HAL_90001 (HAL 9000)]

Ezra Zygmuntowicz wrote:

What if you were to store an array of keys in the
'relationshipkey' field that specifies the relationships(separate
from the primary key). Then your one to many relationship could
actually be a one to one from an element in the array to the child in
the other table.

[snippage]

I did think of something like this, but it just seemed too hairy,
too daunting. I didn't even mention it to Jamey. KB has no way to
store an array field as such in the first place, nor do I know how
you'd really implement it.

Hal

[HAL_90001 (HAL 9000)]

Randy Kramer wrote:

A few things:
   * (aside) the attribution above is a little misleading (not if you read it
carefully, though)--I did not write what is in the item 7

Oops, sometimes I am snip-impaired.

[snip again]

I have read all you said, but I'm at work and haven't time/energy to
reply
at the moment.

In short, I agree with you to the extent that I understand you.
These are
the sort of insights I was hoping to get by moving this discussion to
-talk.
I think it has been enlightening for both me and Jamey.

As for Madeleine -- I think that is the one behind Instiki -- I did
look at
that once, and it seemed there was a huge impedance mismatch with my
needs.
That was just a first impression.

Hal

[Randy_Kramer]

You're welcome!

Maybe there are two different products percolating here. I wonder if Hal is
familiar enough with the the object databases/persistence mechanisms already
available in Ruby (at least I think they exist) to say specifically to their
developers what more he is looking for?

regards,
Randy Kramer

···

On Tuesday 13 September 2005 10:38 am, Jamey Cribbs wrote:

Randy Kramer wrote:
> * Now, not knowing anything (?) about object databases (is that what
>KirbyBase is trying to be) (and not all that much about objects) my

It has helped me to clarify in my head the question, "What do I want
KirbyBase to be?". Now if I only knew the answer.

Thanks, Randy.

[HAL_90001 (HAL 9000)]

Kevin Brown wrote:

In relational database design you DO store a seperate key for each. The
one to many relationship (again, in traditional DB design which doesn't have
much bearing on this anyway) simply means that one item can 'contain'
multiple items.

OK, I guess I was thinking that for a one-to-many you would do a lookup
on the child like child.fldX == parent.fldY (where fldX is not a key
field
as such). But I'm probably talking nonsense.

[snippage]

Hope I'm clearer this time.

I think I understand.

Hal

[CRIBBSJ]

rubyhacker@gmail.com wrote:

Ezra Zygmuntowicz wrote:

What if you were to store an array of keys in the
'relationshipkey' field that specifies the relationships(separate
from the primary key). Then your one to many relationship could
actually be a one to one from an element in the array to the child in
the other table.

[snippage]

I did think of something like this, but it just seemed too hairy,
too daunting. I didn't even mention it to Jamey. KB has no way to
store an array field as such in the first place, nor do I know how
you'd really implement it.

I thought about this, too, when I started thinking about how to implement one-to-many links. The problem with this approach is that what happens, for example, if one of the child records is deleted. Now, KirbyBase has to go through every parent record, check to see if it's array holds that deleted child records key, and then delete key from the array. Feels a little kludgy.

It also doesn't solve the main problem that Hal has with one-to-many links, the fact that they are really only good for #selects, not #inserts, or #updates.

As far as the way the KirbyBase beta implements the mechanics of one-to-many links, IMO I think it is a pretty sound implementation (of course, I'm a little biased). I think what is up in the air now is, how much farther do we push one-to-many links (and possibley other special types). Do we leave them the way they work now, which, to me is pretty similar to how a traditional RDBMS would work, or, do we work to make them truly "object symetrical" (how's that for making up a non-sensical term) so that, no matter how you push/pull/bend/stretch the one-to-many link "thing", KirbyBase does the right thing. Kind of like Silly Putty; you can stretch it out and plaster it all over the Sunday Comics and it still fits back inside it's egg.

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.