Randy said:
* 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.
