On Sep 14, 2005, at 1:50 AM, Hal Fulton wrote:

> 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?

I agree. I wish it was smarter. Originally I had it learn the  
database on initialization, but that precludes the use of .find, and  
would have each new instance hit the db (OTOH maybe I could have it  
do the reflection on the first call of find OR the first  
instantiation and store the results in the class. Hmmm.... I think I  
migth do that the next time I hack on this). Would it be acceptable  
to do something like

class Author < KirbyRecord::Base
end

KirbyRecord::Base.open_database( )

Author.inform_about_table

Of course thats ugly for its own reasons

> 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?
>

Well there's basically 2 reasons for inheritance here. 1) I'm doing  
an ActiveRecord work-alike and I've never written an ORM before, so  
when in doubt its been steal the ActiveRecord way of doing things and  
2) It does make sense if instead of thinking of Author as an author  
object that persists to a db, you rather think of it as a Row object.  
class << Author is kind of the table and an instance of Author is a  
row in the author table. KirbyRecord::Base should maybe be called  
KirbyRecord::Row.

> BTW, I think to_sym is preferred over intern lately.
>

  Sorry, I've been reading Lisp books 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.
>

This shouldn't be too hard, but it would be a slightly different design.

> 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?
>

It could be added, yes, but currently KR builds itself from the  
existing db, not the other way around. It would probably be something  
like

class Author < KirbyRecord::Base
     set_default_for_cols :published => true
end

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

Well I had a couple of ideas.
1) have a corresponding add_book method for things like get_book  
(using the Author example)

or

2) have get_book not return an Array but some other enumerable object  
with an overloaded <<, append, etc. that would do roughly

def <<(book_obj)
      book_ob.set_author_id <my owning author's recno>
      book_obj.save
end

> 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??
>

If KirbyRecord is to become purely an ORM, no I don't think so. If  
it's going to be a set of abstractions over KirbyBase I could see a  
way to sort of do an open table. Something along the lines of (in  
pseudo-kb DDL)

table open_struct_obj
recno
end

table open_struct_field_something
recno
open_struct_obj_id
something OfSomeType
end

(I believe this is called a star pattern or design)

For every field you wanted you would add another table. I could see  
some sort of conveince class / module what have you to ease the  
creation of setups like this.

>
> Thanks,
> Hal
>
>
>