From: Hal Fulton <hal9000@...>
Date: 2005-09-14T14:50:27+09:00
Subject: Re: KirbyBase [ANN (sort-of)] proof-of-concept KirbyBase ORM

Logan Capaldo wrote:
> 
> Well after hacking away today for a couple of hours I've come up with  
> the beginnings of a rudimentary ORM for KirbyBase. I'll post what I  
> have so far, and people can let me know if they are interested in a  
> more complete version. 

So far I'm interested.

> It currently looks a lot like ActiveRecord,  but 
> obviously not as powerful. First it doesn't do ActiveRecords  
> pluralization magic, although that should be easy to add. 

I'm not sure if it's really necessary.

 > Some other problems include that  it
> doesn't yet do ruby-esque getters and setters (ie. obj.something,  and 
> obj.something = value) instead it has get_something and  set_something 
> methods. I did this since I was just hacking away its  easily remedied 
> if anyone shows any interest in my continuing this.  

Seems interesting to me. Should be very little change in code.

> One other thing, it 
> does not make use of KirbyBase's Link type yet,  although if it did, it 
> would probably be better. Again something to  add if anyone really wants 
> to use this. 

Makes sense. Jamey may change the Link stuff though of course.

> 
> KirbyRecord::Base.open_database( )
> 
> class Author < KirbyRecord::Base
>         has_many :book
> end
> 
> class Book < KirbyRecord::Base
> end

Hmmmm. Having to inherit *after* the open_database
just Feels Wrong somehow. Would it work the same if you
just did the open_database before any db operations?

In fact, I'm not sure I'd do inheritance at all. I'd have
to think about it.

Why do Book and Author have to have an is-a relationship
with KirbyRecord::Base? So you can do Author.find() and
so on?

BTW, I think to_sym is preferred over intern lately.

> class Person < KirbyRecord::Base
> end
> 
> person1 = Person.new
> person1.set_name "John Doe"
> person1.set_age 25
> person1.save

OK, I'm catching on to the reason for the inheritance. Is there
any reason a module wouldn't suffice? I'm not sure it matters
either way, but I tend to include modules more than I actually
inherit.

So far I like the general idea.

Now, some questions:

1. Can KR handle the idea of a (default?) key field for a table?
Could it maybe relieve KB of worrying about that?

2. How do you conceive of handling nested objects of the kind I've
mentioned in this thread?

3. Here's possibly a tough one. I've always wanted an "OpenTable"
in KB -- a table where each row is in essence an OpenStruct -- i.e.,
the fields in each row/object may vary. This is a little tough to
implement in KB -- I had an idea for it but there might be reasons
it wouldn't work. Might it be possible to do this at the KR level
somehow??


Thanks,
Hal