[Nitro] a 'database' entity?

chiron sun chiron.sun at gmail.com
Wed Jun 7 00:17:38 EDT 2006


G'day Kashia

Thanks for your tips to my previous mail.  I'll get on and apply the
information were I'm able and digest new information.  I think a discussion
on one question you raised is useful generally.

I mentioned a 'database entity' (or database object), viz.

w> (technical term a "sub-schema") as an object.  At the data-model-layer

k> Why would you want to have a database object? I mean other than an og 
k> instance (like in  your question ($mysql = Og.setup(...))) would be such 
k> an object.
k> 
k> Do I think too 'low-level'? Done too much `$sql1.exec("")` in php? 
k> But Og is like the _opposite_ of that... *think*

A database entity would be the collection of the table items that one (now)
keeps in their model.rb file.  In technical database terms it is everything
in a "subschema".  (Or some DBMS also name this as "schema".  Pedantically a
"schema" is everything managed by a DBMS, and more of a management item than
anything of application interest.)


My answer to the why question, is the same as my question to:

Why would you want to have a "Post" object?  In the example blog model from
the article you mention ...

   http://rubygarden.org/index.cgi/Libraries/og_tutorial.rdoc

k> Why would you want to have a database object? I mean other than an og 

A database entity is the structure for the tables and other structures that
are all related to the same thing.  A database encapsulates these model
objects as the owner object.

Using the "basic blog model" example from the article, the 'database'
persists as three objects:

   # Blog category

   class Category
      attr_accessor :name
   end

  # Blog posting

  class Post
      attr_accessor :title
      attr_accessor :body
      attr_accessor :author
  end

  # Blog comment

  class Comment
      attr_accessor :title
      attr_accessor :body
      attr_accessor :author
  end


In this simple case, a high-level database entity would be something like:

    # Basic Blog database

    class BasicBlog
       entity  :Category
       entity  :Post
       entity  :Comment
    end 

The database entity encapsulates the model as a whole thing.

There was also a request to identify a programme command

k> library which handles 'packaging a database'.

Generally that is the CONNECT command, or the database name you get when you
use a database systems console client, e.g. with mysql:

    mysql database --user=me  --password=pswd

What is important in the context of my original query is that there is a lot
of house keeping and benefits that come with Og generated and maintained
automatically in the database as beneficial effects from using Og and Glue
and perhaps other toys.  

My notion of structure and encapsulation suggests to me that if a framework
manages internals automatically, then I should not need to know any of the
internals unless I'm curious or actually working on the framework.  

My present understanding is that I can't connect something called
"BasicBlog" and say scan the 'database entity' such as:

    myblog = BasicBlog.new( ... )

    myblog.each do | item |
    {
        ... Clean up old entries ...
    }

I can do something similar if I understand some internals for Og, the major
comment on that is conceptual.  The encapsulation is suitable or not
suitable for the purpose at hand.  I'm outlining the substance of my
observation.  

As a novice player, the result of  Og.setup( ... )  'would' correspond to my
example 
BasicBlog.new( ... )  

Cheers,
       Will.



-----Original Message-----
From: nitro-general-bounces at rubyforge.org
[mailto:nitro-general-bounces at rubyforge.org] On Behalf Of Jonathan Buch
Sent: Wednesday, 7 June 2006 09:01
To: General discussion about Nitro
Subject: Re: [Nitro] Hi -- accessing two databases
Importance: Low

> Essentially the kind of thing that goes into a "User Guide" or 
> "Programmers Guide".  Failing that, I've got an expanded quest ...

A tad older and not using all available goodies, an early tutorial from
George is still very useful:
http://rubygarden.org/index.cgi/Libraries/og_tutorial.rdoc

 ...........<snip>.......

> Model classes are TABLES.
Well.. yes? This is instantly visible in the DB after using the class.
But even if you don't realize this at first, it "just works" like I'd say ;D

 ...........<snip>.......

> On the critical level, there needs to be a way to package one database

Please define 'critical'.

> (technical term a "sub-schema") as an object.  At the data-model-layer

Why would you want to have a database object? I mean other than an og
instance (like in  your question ($mysql = Og.setup(...))) would be such an
object.
Do I think too 'low-level'? Done too much `$sql1.exec("")` in php? But Og is
like the _opposite_ of that... *think*

Please define "sub-schema" here, possibly with a pointer to an appliaction
or a library which handles 'packaging a database'.

 ...........<snip>.......


-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.2/356 - Release Date: 05-Jun-2006
 




More information about the Nitro-general mailing list