KirbyBase

Randy Kramer wrote:

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?

I'm not familiar enough with those, but I'd be happy to know that what
I'm
looking for already exists. :slight_smile: I'd still use KirbyBase for the smaller
problems anyhow.

Some of the things I like about KB are:

1. A clean Rubylike interface
2. Plain text files
3. Option to encrypt/obscure text
4. Single-line text like a CSV (not paragraphs like YAML)
5. Built-in drb support
6. Single-file library, pure Ruby, no dependencies
7. Doesn't store the whole thing in memory at once
8. Data files completely portable across platforms
9. Easily allows complex queries using code blocks

#1 might be easy to come by, #2 also. #3 less so.
#4, beats me. #5, I doubt it. Others, dunno.

In connection with #8, note that on more than on occasion I
have found it impossible to move a DBM data file from one
Linux to another and open it (much less Linux to Windows).

If there is an existing solution like this, please let me
know. Or if there is one "close" that has a very open-minded
developer. :slight_smile:

I'm not *totally* married to the "single-file" idea. If a
solution is to wrap an ORM around KB, that would be OK
with me.

So, what's out there?

Hal

The more I read this thread the more the temptation to try my hand at making an ORM system for KirbyBase grows. I think I'll do some work on it today.

···

On Sep 13, 2005, at 3:02 PM, Jamey Cribbs wrote:

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. :slight_smile:

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.

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. 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. Secondly it doesn't have as many variations of find (but that's mitigated by KirbyBases's use of ruby syntax to perform selections). I've only implemented one kind of relationship (one-to-many, or is it many-to-one, some db guy can correct me on my terminology) using a ActiveRecord-esque has_many method. 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. 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. I learned a couple of things developing this, mostly that @@variables are evil, and that class instance vars are better. Without further ado here is the code. Its followed by some examples:

$ cat kirbyrecord.rb
require 'kirbybase'
module KirbyRecord
         class Base

                 def self.open_database( *kirby_base_new_args )
                         @@db = KirbyBase.new( *kirby_base_new_args )
                 end

                 def self.get_database
                         @@db
                 end

                 def initialize
                         @state = {}
                 end

                 def self.inherited(subclass)
                         subclass.inform_about_table
                         subclass.class_eval do
                                 subclass.fields.each do |name, type|
                                         define_method("get_#{name}".intern) do
                                                 @state[name]
                                         end

                                         define_method("set_#{name}".intern) do |value|
                                                 @state[name] = case type
                                                                 when :String
                                                                          value.to_s
                                                                 when :Integer
                                                                          value.to_i
                                                                 when :Float
                                                                          value.to_f
                                                                 when :Boolean
                                                                          if value then true else false end
                                                                 when :Date
                                                                          value
                                                                 when :DateTime
                                                                          value
                                                                 end
                                         end
                                 end
                         end
                 end

         def self.inform_about_table
                 table = get_database.get_table(table_name)
                 @fields = {}
                 table.field_names.zip( table.field_types ) do |field_name, field_type|
                         @fields[field_name] = field_type
                 end
                 self
         end

         def self.find(card)
                 db = get_database
                 tbl = db.get_table(table_name)
                 results = if block_given? then tbl.select { |r| yield(r) } else tbl.select end
                 obj_results = []
                 if card == :all
                         results.each do |res|
                                 obj = self.new
                                 self.fields.each do |field, type|
                                         obj.instance_eval { @state[field] = res.send(field) }
                                 end
                                 obj_results << obj
                         end
                         return obj_results
                 elsif card == :first
                         obj = self.new
                         res = results.first
                         self.fields.each do |field, type|
                                 obj.instance_eval { @state[field] = res.send(field) }
                         end
                         return obj
                 end
         end

         def self.table_name
                 self.to_s.split(/::/).last.downcase
         end

         def self.fields
                 @fields
         end

         def self.has_many(table_sym)
                 class_eval do
                         define_method("get_#{table_sym}".intern) do
                                 table_class_name = table_sym.to_s.capitalize
                                 rel_table_class = Object.const_get(table_class_name)
                                 results = rel_table_class.find(:all) { |r| r.send("#{self.class.table_name}_id") == @state[:recno] }
                         end
                 end
         end

         def new_record?
                 @state[:recno].nil?
         end

         def save
                 db = self.class.get_database( )
                 tbl = db.get_table(self.class.table_name.intern)
                 data = @state.dup
                 data.delete(:recno)

                 if new_record?
                         @state[:recno] = tbl.insert(data)
                 else
                         tbl.update(data) { |r| r.recno == @state[:recno] }
                 end
                 self
         end

end

% cat setup_example_db.rb
require 'kirbybase'
db = KirbyBase.new

author_tbl = db.create_table(:author, :name, :String)
book_tbl = db.create_table(:book, :title, :String, :author_id, :Integer)

rn = author_tbl.insert(:name => "John Doe")
book_tbl.insert(:title => "Ruby for Dummies", :author_id => rn)
book_tbl.insert(:title => "ORM for REAL Dummies", :author_id => rn)

% ruby setup_example_db.rb

% cat has_many_example.rb
require 'kirbyrecord'

KirbyRecord::Base.open_database( )

class Author < KirbyRecord::Base
         has_many :book
end

class Book < KirbyRecord::Base
end

john_doe = Author.find(:first) { |r| r.name =~ /John Doe/ }
john_doe.get_book.each do |book|
         puts "#{john_doe.get_name} wrote #{book.get_title}"
end

% ruby has_many_example.rb
John Doe wrote Ruby for Dummies
John Doe wrote ORM for REAL Dummies

And so on.

Other neat things

% cat setup_db.rb
require 'kirbybase'
db = KirbyBase.new

person_tbl = db.create_table(:person, :name, :String, :age, :Integer)

% ruby setup_db.rb

% cat person_ex.rb
require 'kirbyrecord'

KirbyRecord::Base.open_database( )

class Person < KirbyRecord::Base
end

person1 = Person.new
person1.set_name "John Doe"
person1.set_age 25
person1.save

person2 = Person.new
person2.set_name "Jane Doe"
person2.set_age 23
person2.save

people = Person.find(:all)

people.each do |person|
         puts "name: #{person.get_name}, age: #{person.get_age}"
         person.set_name( person.get_name + " Smith" )
         person.save
end

people = Person.find(:all)

puts "After updates:"
people.each do |person|
         puts "name: #{person.get_name}, age: #{person.get_age}"
end

% ruby person_ex.rb
name: John Doe, age: 25
name: Jane Doe, age: 23
After updates:
name: John Doe Smith, age: 25
name: Jane Doe Smith, age: 23

Other than that the only thing to mention is that KirbyRecord::Base.open_database( ) takes the same arguments as KirbyBase.new and that you should call it before inheriting from KirbyRecord::Base (incidently anyone have any ideas on how to avoid having to do this?). Also KirbyRecord::Base#find can take a block just like KBTable#select. There are probably lots and lots of bugs.

<snip great stuff>

     I for one think this is pretty sweet. I'm going to play with it and give you some feedback. I think this would definitely be a worthy project to flesh out more.

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

···

On Sep 13, 2005, at 7:57 PM, 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. 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. Secondly it doesn't have as many variations of find (but that's mitigated by KirbyBases's use of ruby syntax to perform selections). I've only implemented one kind of relationship (one-to-many, or is it many-to-one, some db guy can correct me on my terminology) using a ActiveRecord-esque has_many method. 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. 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. I learned a couple of things developing this, mostly that @@variables are evil, and that class instance vars are better. Without further ado here is the code. Its followed by some examples:

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

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

That was fast! :slight_smile:

they are interested in a more complete version. 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. Secondly it doesn't have as many variations of find (but that's mitigated by KirbyBases's use of ruby syntax to perform selections). I've only implemented one kind of relationship (one-to-many, or is it many-to- one, some db guy can correct me on my terminology) using a ActiveRecord-esque has_many method. 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. 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. I learned a couple of things developing this, mostly that @@variables are evil, and that class instance vars are better. Without further ado here is the code. Its followed by some examples:

% cat setup_example_db.rb
require 'kirbybase'
db = KirbyBase.new

author_tbl = db.create_table(:author, :name, :String)
book_tbl = db.create_table(:book, :title, :String, :author_id, :Integer)

rn = author_tbl.insert(:name => "John Doe")
book_tbl.insert(:title => "Ruby for Dummies", :author_id => rn)
book_tbl.insert(:title => "ORM for REAL Dummies", :author_id => rn)

% ruby setup_example_db.rb

% cat has_many_example.rb
require 'kirbyrecord'

KirbyRecord::Base.open_database( )

class Author < KirbyRecord::Base
        has_many :book
end

class Book < KirbyRecord::Base
end

john_doe = Author.find(:first) { |r| r.name =~ /John Doe/ }
john_doe.get_book.each do |book|
        puts "#{john_doe.get_name} wrote #{book.get_title}"
end

% ruby has_many_example.rb
John Doe wrote Ruby for Dummies
John Doe wrote ORM for REAL Dummies

And so on.

Very cool! I don't know much about ActiveRecord (looks like I have some reading to do), but I like this. Just as a comparison, here's the way I would rewrite the has_many example using KirbyBase's new Link_many feature:

author_tbl = db.create_table(:author, :name, :String,
:books, { :DataType => KBResultSet, :Link_many => [:recno, :book, :author_id] })
book_tbl = db.create_table(:book, :title, :String, :author_id, :Integer)

rn = author_tbl.insert(:name => "John Doe")
book_tbl.insert(:title => "Ruby for Dummies", :author_id => rn)
book_tbl.insert(:title => "ORM for REAL Dummies", :author_id => rn)

john_doe = author_tbl.select { |r| r.name =~ /John Doe/ }.first
john_doe.books.each do |book|
        puts "#{john_doe.name} wrote #{book.title}"
end

Other neat things

% cat setup_db.rb
require 'kirbybase'
db = KirbyBase.new

person_tbl = db.create_table(:person, :name, :String, :age, :Integer)

% ruby setup_db.rb

% cat person_ex.rb
require 'kirbyrecord'

KirbyRecord::Base.open_database( )

class Person < KirbyRecord::Base
end

person1 = Person.new
person1.set_name "John Doe"
person1.set_age 25
person1.save

That's very cool!

Other than that the only thing to mention is that KirbyRecord::Base.open_database( ) takes the same arguments as KirbyBase.new and that you should call it before inheriting from KirbyRecord::Base (incidently anyone have any ideas on how to avoid having to do this?). Also KirbyRecord::Base#find can take a block just like KBTable#select. There are probably lots and lots of bugs.

Very nice work.

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.

Before you go too far with this, you might want to check out Og's KirbyBase
adapter. I've haven't delved too much into it, but it might be just what
you're looking for. I realize that Og is a completely different way of
looking at the Object-Database connection than ActiveRecord, but it may be
worth your while.

There's major work being done on Og at the moment, so you may want to also
check out the patches that Ysabel has prepared: 'darcs get
http://darcs.ysabel.org/nitro/og-store&#39;\.

HTH,

- Dimitri

···

On 9/14/05, Jamey Cribbs <cribbsj@oakwood.org> 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

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. :wink:

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.

···

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

Thanks,
Hal

Ok I'm including a patch that lets you connect after the inherit.

eg.

class Author < KirbyRecord::Base
end

KirbyRecord::Base.open_database( )

authors = Author.find(:all)

author = Author.new # will also cause the reflection and modifications to the Author class to occurr

  This patch also incidently removes the reliance on the inherited hook, so it would be enitrely possible to make this a module. I'm still mulling that over, and I want to hear some more thoughts on the subject before I decide.

kirbyrecord.smartinform.patch (1.8 KB)

···

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

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.

Well don't I feel silly. *goes over to check out Og*

···

On Sep 14, 2005, at 10:01 AM, Dimitri Aivaliotis wrote:

On 9/14/05, Jamey Cribbs <cribbsj@oakwood.org> 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

Before you go too far with this, you might want to check out Og's KirbyBase
adapter. I've haven't delved too much into it, but it might be just what
you're looking for. I realize that Og is a completely different way of
looking at the Object-Database connection than ActiveRecord, but it may be
worth your while.

There's major work being done on Og at the moment, so you may want to also
check out the patches that Ysabel has prepared: 'darcs get
http://darcs.ysabel.org/nitro/og-store&#39;\.

HTH,

- Dimitri

Well after now having looked through some Og examples (didn't get around to looking at any of the code don't have darcs installed, will probably do that at some point), I see that a) its very cool b) it is indeed completely different than AR and c) Its probably exactly what Hal wants. Oh
and d) I still think I'll continue working on KirbyRecord for now, cause there are bound to be people out there who would like an AR style ORM for KirbyBase. Right? Hello? *cricket cricket cricket*. Joking :wink:

···

On Sep 14, 2005, at 10:01 AM, Dimitri Aivaliotis wrote:

On 9/14/05, Jamey Cribbs <cribbsj@oakwood.org> 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

Before you go too far with this, you might want to check out Og's KirbyBase
adapter. I've haven't delved too much into it, but it might be just what
you're looking for. I realize that Og is a completely different way of
looking at the Object-Database connection than ActiveRecord, but it may be
worth your while.

There's major work being done on Og at the moment, so you may want to also
check out the patches that Ysabel has prepared: 'darcs get
http://darcs.ysabel.org/nitro/og-store&#39;\.

HTH,

- Dimitri

Well after now having looked through some Og examples (didn't get
around to looking at any of the code don't have darcs installed, will
probably do that at some point),

You only need darcs if you wanted to check out Ysabel's patches. The main Og
code can be installed as a gem: 'gem install og' or you can get it from
Nitro's Rubyforge page: http://rubyforge.org/projects/nitro

I see that a) its very cool b) it
is indeed completely different than AR and c) Its probably exactly
what Hal wants. Oh
and d) I still think I'll continue working on KirbyRecord for now,
cause there are bound to be people out there who would like an AR
style ORM for KirbyBase.

Go for it! The more solutions the better.

- Dimitri

···

On 9/14/05, Logan Capaldo <logancapaldo@gmail.com> wrote:

Well after now having looked through some Og examples (didn't get
around to looking at any of the code don't have darcs installed, will
probably do that at some point), I see that a) its very cool b) it
is indeed completely different than AR and c) Its probably exactly
what Hal wants. Oh
and d) I still think I'll continue working on KirbyRecord for now,
cause there are bound to be people out there who would like an AR
style ORM for KirbyBase. Right? Hello? *cricket cricket cricket*.
Joking :wink:

I am glad you like Og. But if you would like to work on a kirbybase adapter
you really need to download ysabel patches. They will be integrated in
the main source tree very soon.

BTW, I hope you are not reading the examples from the old tutorial. A
ton of new features have been implemented since, I would suggest that
you take a look at the test cases, or the RELEASES file for more
examples.

regards,
George.

···

--

http://www.navel.gr

I will take a look at those when I get a chance

···

On Sep 14, 2005, at 11:26 AM, George Moschovitis wrote:

I am glad you like Og. But if you would like to work on a kirbybase adapter
you really need to download ysabel patches. They will be integrated in
the main source tree very soon.

BTW, I hope you are not reading the examples from the old tutorial. A
ton of new features have been implemented since, I would suggest that
you take a look at the test cases, or the RELEASES file for more
examples.

regards,
George.

--
http://www.gmosx.com
http://www.navel.gr
http://www.nitrohq.com

Here Here! I think KirbyRecord would be great to use in scripts and maybe even in small rails projects. Seeing as how its pure ruby it would make for very easy installation and usage.

Keep it up!
-Ezra Zygmuntowicz
Yakima Herald-Republic
WebMaster
509-577-7732
ezra@yakima-herald.com

···

On Sep 14, 2005, at 8:07 AM, Dimitri Aivaliotis wrote:

On 9/14/05, Logan Capaldo <logancapaldo@gmail.com> wrote:

Well after now having looked through some Og examples (didn't get
around to looking at any of the code don't have darcs installed, will
probably do that at some point),

You only need darcs if you wanted to check out Ysabel's patches. The main Og
code can be installed as a gem: 'gem install og' or you can get it from
Nitro's Rubyforge page: http://rubyforge.org/projects/nitro

I see that a) its very cool b) it
is indeed completely different than AR and c) Its probably exactly
what Hal wants. Oh
and d) I still think I'll continue working on KirbyRecord for now,
cause there are bound to be people out there who would like an AR
style ORM for KirbyBase.

Go for it! The more solutions the better.

- Dimitri

Dimitri Aivaliotis wrote:

You only need darcs if you wanted to check out Ysabel's patches. The main Og code can be installed as a gem: 'gem install og' or you can get it from Nitro's Rubyforge page: http://rubyforge.org/projects/nitro

I will look at this further later... right now I'm swamped.

I don't have darcs and have never even heard of it. :slight_smile:

I see that a) its very cool b) it
is indeed completely different than AR and c) Its probably exactly
what Hal wants. Oh
and d) I still think I'll continue working on KirbyRecord for now,
cause there are bound to be people out there who would like an AR
style ORM for KirbyBase.

Go for it! The more solutions the better.

Og does look really cool. I glanced at some stuff on Rubygarden
that is probably out of date.

Do you still pass in a SQL-like string to the #select method? That
begs for code blocks IMO.

What are some recent changes in Og? Are they doc'd online? And
what is the state of the KB adapter?

Thanks,
Hal

···

On 9/14/05, Logan Capaldo <logancapaldo@gmail.com> wrote:

I will look at this further later... right now I'm swamped.

I understand - me, too. :slight_smile:

I don't have darcs and have never even heard of it. :slight_smile:

Darcs is a revision control system. It's based on patches, kind of similar
to Arch, although there are some major differences. Check out
İddaa Bahis Siteleri - Burada En İyi Siteler Var.

Og does look really cool. I glanced at some stuff on Rubygarden
that is probably out of date.

Do you still pass in a SQL-like string to the #select method? That
begs for code blocks IMO.

What are some recent changes in Og? Are they doc'd online? And
what is the state of the KB adapter?

Ysabel can probably answer these questions better herself.
- Dimitri

···

On 9/15/05, Hal Fulton <hal9000@hypermetrics.com> wrote: