From: Kirk Haines <khaines@...>
Date: 2005-10-26T13:52:48+09:00
Subject: Re: The "perfect" ORM?

--Boundary-00=_6vwXD+nlLoPJ8AX
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

On Tuesday 25 October 2005 6:11 pm, Hal Fulton wrote:
> For many weeks I have had this at the back of my mind.
>
> I want a really good ORM that is highly non-intrusive
> (e.g., I don't have to inherit and I don't have to
> clutter my classes and objects with metadata).

orm = KSDatabase.new('kirbybase:///var/db/msds',:pollute => true)

sodiums = Chemicals.chemical_name.like('sodium')
chlorides = Chemicals.chemical_name.like('chlorides')
sodium_chlorides = sodiums & chlorides

or

sodium_chlorides = Chemicals.select do |c|
  (c.chemical_name =~ 'sodium') & (c.chemical_name =~ 'chloride)
end

Chemicals.new({:chemical_name => 'potassium chloride'})

schools_with_nacl = orm.select(:Schools, :Inventories, :Chemicals) do |s,i,c|
  (c.chemical_name == 'sodium chloride') &
  (i.chemical_idx == c.idx) &
  (i.school_idx == s.idx)
end

If there is sufficient meta data in Kirbybase to identify relationships between tables (such as can be done in some dbs with foregin key constraints and the like):

schools_with_nacl = Chemicals.chemical_name.is('sodium chloride').inventories.collect {|i| i.school}.uniq

Otherwise one would have to specifically declare relationships:

Chemicals.to_many(:relationship => :inventories, :foreign_table => :inventories, :foreign_key => :chemical_idx)
Inventories.to_one(:relationship => :school, :foreign_table => :school, :local_key => :school_idx)

Which, using just a smidge of convention over configuration logic, could be written as simply as:

Chemicals.to_many(:relationship => :inventories)
Inventories.to_one(:relationsip => :school)

Now, to be honest, you can't do this, quite like this, yet.  As Kansas works right now, database connection is uglier, there is no adaptor for KirbyBase, relationships must be manually declared either with that mechanism or with a class declaration, and a few other things.  However, a couple days ago I started gutting parts of Kansas to modularize them, clean up interfaces, sniff metadata and act on it better, and make it easy to do things like write adaptors to non-SQL data sources like KirbyBase, or to give better optimization of generated queries on databases that allow it, such as by using hinting with Oracle queries, for example.

The above examples come directly from my current plan of how I want the library to work, based on my needs and the input that I have gotten from others.  It's completely subject to change from internal or external influence at this point, as I'm still working on the modularization of the query generation/db interface code.  The motivation for this, quite honestly, is so that I can have an adaptor to KirbyBase or even directly to a directory of CSV files which can be treated as a database of tables, or to other non-db data sources.


Kirk Haines
--Boundary-00=_6vwXD+nlLoPJ8AX--