[Nitro] a 'database' entity?

Jonas Pfenniger zimba.tm at gmail.com
Sun Jun 11 12:54:51 EDT 2006

Hi William,

On 11/06/06, * William <william.full.moon at gmail.com> wrote
> 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.

Yes plus the CRUD methods that Og doesn't provide. It only interfaces them.

> The Og::Manager does _not_ implement a database.  It can and does pull in
> tables that are not part of the database.

Ok I get you're point and I may have misexpressed myself but it's not
what I meant. Og::Manager is only a part of the logical glue between
the database and ruby.

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

Because Og still has some bugs doesn't mean the design is wrong.

> 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?

Dependent of what ?

> There is no integration of the data for the tables that were not
> interesting to application #A.

What kind of integration are you looking for ?

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

Well, Og.setup is only a utility that :
 * Sets default options
 * Start an Og::Manager
 * Tells him to manage all classes

If you have a set of entities, say [A, B, C, D], you could theorically use
man1 = Og::Manager.new(options1)
man2 = Og::Manager.new(options2)
man1.manage_classes A,B
man2.manage_classes C,D

> It is a cheap shot to suggest that managed_classes are not managed very well
> in the current implementation.

That's possible

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

No, the tables and database are only the side effects of using Og. Og
is there to allow you to think in term of persistable objects. If you
would like to introduce grouping, then it should have nothing to do
with real databases. Like you said, Og is usable with flat files or
memory stores.

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

Yes but it has nothing to do with databases. If you want to unify your
authentication scheme, you generally create a library that each of the
four applications would use. Now it is up to you to decide where you
want to store the data when configuring Og. You could have all four
apps plus the lib in the save database, or each in his own with the
library in a separate one, using multiple Og::Manager.

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

If you want somebody to code something for you, you'd better not use
that argument :-p

I think that you don't fully understand the goals of Og and that you
want to map a traditional RDBM view to Og. Don't take it as a critic.
I've made the same error when starting with Og. I think this is a
common new commer error. When X doesn't fit your way of thinking you
start saying it's wrong instead of trying to understand how it works

I can assure you that Og have some shortcoming but I don't think it's
the case here. Like you stated, a file or memory can be used to
persist data, even if they don't have a "database" concept. You can
think that the database in the database server is just a location
(like the path to the file) to store your datas. Nothing more.

Again, I may have missed the point. Maybe to make things more clear
you can tell us what real world problem you try to solve or if it is
an academic point of view ?



More information about the Nitro-general mailing list