KirbyBase

[Jamey Cribbs]

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.

 

[Logan Capaldo]

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.

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.

 

[Logan Capaldo]

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 ate

value

when ateTime

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.findall)
{ |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.deleterecno)

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

end
end

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

author_tbl = db.create_tableauthor, :name, :String)
book_tbl = db.create_tablebook, :title, :String, :author_id, :Integer)

rn = author_tbl.insertname => "John Doe")
book_tbl.inserttitle => "Ruby for Dummies", :author_id => rn)
book_tbl.inserttitle => "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.findfirst) { |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_tableperson, :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.findall)

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.findall)

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.

 

[Ezra Zygmuntowicz]

--Apple-Mail-5-184054240
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed

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:

<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
(e-mail address removed)
509-577-7732

--Apple-Mail-5-184054240--

 

[Hal Fulton]

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

 

[Jamey Cribbs]

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!

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_tableauthor, :name, :String)
book_tbl = db.create_tablebook, :title, :String, :author_id, :Integer)

rn = author_tbl.insertname => "John Doe")
book_tbl.inserttitle => "Ruby for Dummies", :author_id => rn)
book_tbl.inserttitle => "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.findfirst) { |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_tableauthor, :name, :String,
:books, { ataType => KBResultSet, :Link_many => [:recno, :book,
:author_id] })
book_tbl = db.create_tablebook, :title, :String, :author_id, :Integer)

rn = author_tbl.insertname => "John Doe")
book_tbl.inserttitle => "Ruby for Dummies", :author_id => rn)
book_tbl.inserttitle => "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_tableperson, :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.

 

[Dimitri Aivaliotis]

------=_Part_18907_11909224.1126706499795
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

=20
Logan Capaldo wrote:
=20
=20
=20

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

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

HTH,

- Dimitri

------=_Part_18907_11909224.1126706499795--

 

[Logan Capaldo]

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'.

HTH,

- Dimitri

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

 

[Logan Capaldo]

So far I'm interested.



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



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



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



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.

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 ublished => 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.

 

[Logan Capaldo]

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'.

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

 

[Dimitri Aivaliotis]

------=_Part_19193_13522900.1126710399392
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

=20
=20
=20
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 O=
g=20
code can be installed as a gem: 'gem install og' or you can get it from=20
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.=20

Go for it! The more solutions the better.=20

- Dimitri

------=_Part_19193_13522900.1126710399392--

 

[George Moschovitis]

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

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.



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

 

[Logan Capaldo]

--Apple-Mail-2-228640982
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=UTF-8;
delsp=yes;
format=flowed

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.



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.

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

eg.

class Author < KirbyRecord::Base
end

KirbyRecord::Base.open_database( )

authors =3D Author.findall)

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


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

subject before I decide.

=EF=BF=BC=

--Apple-Mail-2-228640982
Content-Type: multipart/mixed;
boundary=Apple-Mail-3-228640982


--Apple-Mail-3-228640982
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><BR><DIV><DIV>On Sep 14, 2005, =
at 1:50 AM, Hal Fulton wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">Hmmmm. Having to inherit =
*after* the open_database</FONT></P> <P style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">just Feels Wrong somehow. Would it work the same if =
you</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">just did =
the open_database before any db operations?</FONT></P> <P style=3D"margin:=
0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: =
14.0px"><BR></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">In fact, =
I'm not sure I'd do inheritance at all. I'd have</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">to think about =
it.</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px =
Helvetica; min-height: 14.0px"><BR></P> <P style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Why do Book and Author have to have an is-a =
relationship</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">with KirbyRecord::Base? So you can do Author.find() =
and</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">so =
on?</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px =
Helvetica; min-height: 14.0px"><BR></P> <P style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">BTW, I think to_sym is preferred over intern =
lately.</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: =
12.0px Helvetica; min-height: 14.0px"><BR></P> <BR><BLOCKQUOTE =
type=3D"cite"><P style=3D"margin: 0.0px 0.0px 0.0px 10.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">class =
Person &lt; KirbyRecord::Base</FONT></P> <P style=3D"margin: 0.0px 0.0px =
0.0px 10.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">end</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px =
10.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">person1 =3D Person.new</FONT></P> <P style=3D"margin: 0.0px =
0.0px 0.0px 10.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">person1.set_name "John Doe"</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 10.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">person1.set_age =
25</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 10.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">person1.save</FONT></P> <BR></BLOCKQUOTE><P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: =
14.0px"><BR></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">OK, I'm =
catching on to the reason for the inheritance. Is there</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">any reason a module wouldn't =
suffice? I'm not sure it matters</FONT></P> <P style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">either way, but I tend to include modules more than I =
actually</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">inherit.</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px =
0.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">So far I like the general =
idea.</FONT></P> <BR =
class=3D"Apple-interchange-newline"></BLOCKQUOTE></DIV><BR><DIV>Ok I'm =
including a patch that lets you connect after the inherit.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>eg.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>class Author &lt; =
KirbyRecord::Base</DIV><DIV>end</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>KirbyRecord::Base.open_databa=
se( )</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>authors =
=3D Author.findall)</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>author =3D Author.new # =
will also cause the reflection and modifications to the Author class to =
occurr</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>=A0This 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.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV><SPAN></SPAN></DIV></BODY></H=
TML>=

--Apple-Mail-3-228640982
Content-Transfer-Encoding: 7bit
Content-Type: application/octet-stream;
x-unix-mode=0644;
name="kirbyrecord.smartinform.patch"
Content-Disposition: attachment;
filename=kirbyrecord.smartinform.patch

--- kirbyrecord.rb.0 2005-09-13 22:25:40.000000000 -0400
+++ kirbyrecord.rb 2005-09-14 11:27:01.000000000 -0400
@@ -11,47 +11,49 @@
end

def initialize
+ self.class.inform_about_table
@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 ate
- value
- when ateTime
- value
- end
- end
- end
- end
- end

- def self.inform_about_table
+ def self.inform_about_table(force = false)
+ unless force
+ return self if @fields
+ end
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
+ class_eval do
+ 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 ate
+ value
+ when ateTime
+ value
+ end
+ end
+ end
+ end
self
end

def self.find(card)
+ inform_about_table
db = get_database
tbl = db.get_table(table_name)
results = if block_given? then tbl.select { |r| yield(r) } else tbl.select end

--Apple-Mail-3-228640982
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
charset=US-ASCII

<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><SPAN></SPAN></DIV></BODY></HTML>
--Apple-Mail-3-228640982--

--Apple-Mail-2-228640982--

 

[Logan Capaldo]

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.

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

 

[Ezra Zygmuntowicz]

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




Go for it! The more solutions the better.

- Dimitri

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
(e-mail address removed)

 

[Hal Fulton]

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.

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

 

[Dimitri Aivaliotis]

------=_Part_22473_1002282.1126765980656
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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

I understand - me, too. =20

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


Darcs is a revision control system. It's based on patches, kind of similar=
=20
to Arch, although there are some major differences. Check out=20
http://abridgegame.org/darcs/.

=20
Og does look really cool. I glanced at some stuff on Rubygarden
that is probably out of date.
=20
Do you still pass in a SQL-like string to the #select method? That
begs for code blocks IMO.
=20
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

------=_Part_22473_1002282.1126765980656--