[Nitro] a 'database' entity?
william.full.moon at gmail.com
Sun Jun 11 11:13:27 EDT 2006
I was writing earlier on this notion. I can see your point of view, it
makes sense and fits with most of the Og behaviour/design.
Under the conditions outlined, you can't call Og a "database" access.
An appropriate description I came-up with to identify Og is:
'Object persistence via logical data tables"
That leaves the implementation flexible for memory based schemes and
alternatives not restricted to relational database engines. This is a
truth, you only need a regular table structure of rows and columns to
implement an underlying Og support structure.
People indexed entries can utilise an ISAM based store. Or a flat-file
store can implement it's own indexing.
That fully complies with the requirements expressed:
z> A database representation is already done in Og when you start an
z> I think this is a better approach than using a class for the following
z> reasons :
z> * Tables that are not managed by Og are not interesting because not
z> usable in Og
z> * It would make things more static. The database name is something you
z> want to change more often (eg. different environment like debug
z> or live)
The Og::Manager does _not_ implement a database. It can and does pull in
tables that are not part of the database. You may have missed my initial
exercise to open old-database and copy records to a new-database. Simply
opening TWO distinct "og::Manager instances" was problematic. Not only
because of my ignorance of Oq, also by design deliberate or otherwise.
As you say, I can open some tables with Og and work only with those
entities. What do I do when application #A only include some dependent
table? There is no integration of the data for the tables that were not
interesting to application #A. Databases are a really useful and necessary
tool for software development. When you don't have one, you will
re-discover lots and lots of bugs that databases left behind 15-20 years
z> for that class all the time without having a real benefit. Or I missed
z> point. cf. managed_classes
Again, I think instantiated managed_class only accesses tables given in the
Og.Setup(...). And none of any Other tables in a database. And the also
"vacuum up" other database classes NOT in the database. I discovered this
in the copy old-db to new-db exercise (see earlier post).
It is a cheap shot to suggest that managed_classes are not managed very well
in the current implementation. Much discussion can happen because of
different requirements for something that persists data. In your case, a
database is the tables your application needs to use (as I understand your
In the Og/Nitro context would that mean that my web site would have a Blog
application, a Wiki application, a cookbook application and (say) a forums
app. Each of those four applications would be in separate data-silos. We
both know that I don't want four user_registration tables, so each
application presumably shared the user_registration table. That is just
good Object oriented decomposition.
In a few years or months time someone will get a good idea that uses one or
more data-silos in some brilliant way! The difference between a 'clean'
data model and persistent entity-relations (which is what
OG::managed_classes is), will be the time and money it costs to make the
good idea work and the number of extra bugs due to the good idea spread over
the five applications (four plus one).
I _want_ a database class, that give me a wholistic data model. I wasn't
asking someone to agree with me. It is worth clearly explaining what I am
What is misleading for people like me is that ActiveRecord and Og sit on top
of database API-s and using them for managed table access.
I have to back down. Any bunch of text files can be a "database". I saw
one nice database that read in a bunch of XML files and ran-live in memory
until the database was saved. The purpose of a database-entity is to
mediate access to a database object implementation.
In this discussion Og would use a Database entity -- It must use one for
postgresql, sqlite, mysql, etc because they layers implement a database
entity. The difference is that the Og layer is exercising the database
underneath as a simple file/table manager.
That's fine with me, as long as I'm not confused and as long as others
especially the newly arrived are tapped on the shoulder and told how things
From: nitro-general-bounces at rubyforge.org
[mailto:nitro-general-bounces at rubyforge.org] On Behalf Of Jonas Pfenniger
Sent: Saturday, 10 June 2006 22:55
To: General discussion about Nitro
Subject: Re: [Nitro] a 'database' entity?
== Class for Database representation
Og uses some database as a store for the various datas. By defining
entities, you define the structure of what you want to store in the
database. Looking like this, the database is only usefull to put and
retrieve the datas.
A database representation is already done in Og when you start an
Og::Manager. I think this is a better approach than using a class for the
following reasons :
* Tables that are not managed by Og are not interesting because not usable
* It would make things more static. The database name is something you want
to change more often (eg. different environment like debug or
Naturally, the database class could have an extra attribute to tell it's
database name. But you'll have to write extra code for that class all the
time without having a real benefit. Or I missed the point. cf.
What I think is the next thing to do is cross queries. Og (and AR) transform
the relational database into a hierarchical database. Where objects
belongs_to other objects, ... In some cases it make it hard / inefficient to
consilitate datas in different entities.
Nitro-general mailing list
Nitro-general at rubyforge.org
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.3/360 - Release Date: 09-Jun-2006
More information about the Nitro-general