[Nitro] Hi -- accessing two databases

Jonathan Buch john at oxyliquit.de
Tue Jun 6 19:00:59 EDT 2006


> Can someone point me to a basic (descriptive) documentation on Og.
> 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:

>  >  is Timestamped
This is a helper, look in og/lib/glue/ for all standard helpers.

>  >  include Sweeper
This is caching, my advise: stay away from that right now until George
writes a tutorial about that like he promised some time ago (George, ping)

>  >  property :title, String, :uniq => true
>  >  property :body, String, :control => :textarea

> Not every "label" and "symbol" is completely intuitive.  I've discovered
> that Taggable can create at least two un-documented tables.  Automation  
> is fine.  When it comes to what goes on a database, it all has to be  
> "accounted for" and "tracked".

Og tracks your changes, that is all that is needed.

To quote "robby on rails":
>> UPDATE: DHH responded to this post and provided a link which discusses 
>> Application Database[1] versus Integrated Database[2]
>> [1]http://martinfowler.com/bliki/ApplicationDatabase.html
>> [2]http://martinfowler.com/bliki/IntegrationDatabase.html

> I find some Og behaviours bordering on frightening (hence my added  
> 'warning' on the question).  I have spent my evening 'diagnosing' the 
> changes in my "Test" database.  They are both interesting and  
> inscrutable.

This are not so much 'changes' as things you type in your Og model get
reflected to your Database instantly (well, after reloading the app).

> 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  

> Og generates apparently missing tables.
Heh.. yes? I'm not sure about your ruby background, but I have the hunch
that you might come from the ActiveRecord front (I think AR doesn't create
tables for you). Maybe that should be clarified on a "big picture" page
on the new nitroproject page (when it goes live)?

> Early tests made new tables. (Good thing I have a back-up).
Um.. yes? Don't run on production systems while developing your new DB
layout, this holds true for old-style hand editing as well ;)

> Table names are based on the class-name (d'er).
uhm.. sure.. how'd you like it?

> Make sure the class names are the final table names you want.
Nope, you can change the table name.

class Asdf
   ann self, :sql_table => "TableName"

A tad undocumented perhaps, but it's good to match the DB names and Model
names anyway (application database).

> These points may be obvious to Og mechanics. For us newbies they can be
> potential pitfalls.

Yep, true that ^^;

> See this question.  It has become very interesting as a learning  
> exercise:
>     http://oxyliquit.de/question/58

Generally, please don't use Questions to carry additional information,
better use a Tip with a good topic.
(Search reasons, so that new users who begin to search on Oxywtf will get
the most 'relevant' results first, and don't have to look for information
in a question on a slightly different topic)

> I want to keep the question manageable.  If someone can begin with the
> functions (descriptive) of the options that one may use with a model file
> and the managed classes' options.

[to be filled]

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

> Og is some tables with relations.

Isn't that what 'Data' means? Some data floating around (somewhere I don't
really care) which have dependencies and I can get them in any way I want.

> I say this because the answer to my question is at the (unit) database 
> logical level and not with collected "tables".

Define 'logical level'?

Can I get you to rephrase this whole paragraph? I'm sorry but I think we're
just on a different level of application coding somehow.

Or did I get the meaning of 'database object' wrong?
Well, in the case you meant that a database object is a `Foo.new` in the
Database, so that Og manages a 'real' ORDBMS then the answer is no.
Question is, why should it? Tables are so much more convenient, at least
for me :P

> Some of the info I'm looking for was on the nitrohq wiki -- Is that  
> going to be restored?

I sure hope so... /me glares at big G. ;)


Feel the love

More information about the Nitro-general mailing list