[Nitro] a 'database' entity?
john at oxyliquit.de
Fri Jun 9 06:02:37 EDT 2006
up front, if I sounded a bit too 'defensive', I apologize for that, it
really wasn't my intention :)
I really like your ideas, and others do to (there was talk on #nitro
about this discussion).
Quotes (so we don't appear to be talking behind you back about you):
<bsoto> Man, Chiron and zimba need to talk. It's like Og 2.0 all over
* FabianB wonders how this database guru chiron got interested in og.
<FabianB> this sounds very much like an academic discussion.. it might help
Og though, if someone understands it and can improve Og in some
the ways he explains.. maybe he himself, if he's interested long
enough and dives deep into Og
> Thanks for reviewing my comments. The 'theory' however is not mine.
> There is quite a body of work on what a database is, what it needs to
> do, etc.
> I'm only taking credit for my errors in describing 'theory' or
> misunderstandings about Og or ruby.
> I have written a couple of databases from the ISAM-up. And I feel I can
> comment on places where "there be dragons". Unfortunately I think
> quality tools like mysql or oracle encourage me to take some things I
> think of as "basic" for granted.
[snip from further down]
> Back onto your comments, I see what you are saying, and I believe I can
> see "why" you see things this way. I'd like to ask you to accept that
> there are some good reasons for holding an alternative point of view on
> this. Perhaps I phrased my earlier description poorly.
I think here lies the problem *sweatdrop* The difference of experience
between you and me, and the level on which the discussion is on.
What I think I have problems with, is the theory/academic-level of stuff :)
My brain is full of 'how can I solve this problem at hand' so I try to
show you solutions as well, which you maybe didn't want (like that).
I hope that more people comment on your posts (they sure attract attention)
so you get more views than mine :)
> There's good descriptions for the things that make databases 'reliable',
> 'trustworthy' and 'consistent'. This paper on data integrity from
> Oracle is nicely done:
My first reaction to this would be
'But the postgres adapter adds constraints, exactly like the url above!'
which would probably be true in one sense, but I think it's not what you
> Some people will find it interesting, to observe that Og and ActiveRecord
> are mechanisms to implement "hierarchical databases" atop (so far)
> relational database engines. Postgress remembers its hierarchical roots.
> Before foreign key tables and joins hierarchical databases saved
> (on-disk references) to dependant and back to parent rows. A big problem
> was referential integrity. When I update my Foot, my Toe instances must
> 'know'. All the hierarchical issues and advantages are likely to
> come-up as more people use these OO persistent data.
I can't really comment on this section, my knowledge about database
is very limited.
Am I right that this is about reliability/consistency?
> I have been working through the Og documents and source in order to
> document a catalogue of attributes, and features. In the process I'm
> realising some DB things that I'd like. At some point I hope to have
> a picture of what's there and a more informed opinion.
As the quote from FabianB: I too hope that you'll stay around, your ideas
are very good and a little more professional/better educated than probably
any of us ^^;
> As an aside, is there is a place for a discovery lexxer to enumerate
> class attributes (I have seen something along those lines. The automatic
> documentation doesn't seem to list legitimate options and attributes.)
I have no idea what a discovery lexxer is :D (even google didn't want to
tell me). My guess what you mean by class attributes is (please correct me,
and I will try to provide a better answer):
property :name, String, :unique => true
Programmatically (like discovery lexxer sounds) it is impossible to find
the possible options, even if you had a perfect Ruby parser, you would have
a hell of a time checking for stuff that is valid there.
Best is to look in the Og code for the actual implementation (as long
as the wiki is still down, which had these informations):
og/lib/og/stores/sql.rb:650:def resolve_options(klass, options)
There it is quite clearly shown what the options are and what they do.
Yes I realize that normally people don't want to look at the implementation
of libraries (like I normally don't either), but 'unfortunately' with
Nitro/Og not being as stable/finished/polished/well-documented/complete
as one would wish it was.
`grep` is my tool of choice :P
[snip, the rest of the message]
I will not comment on the rest of the message, as it is all valid and I
can't find anything to add.
George, please read it carefully, as it is a 'bug-report', kinda :)
Yet some more general Og directions:
$psql = Og.setup(
:destroy => false,
:evolve_schema => true,
:store => :psql,
:name => 'oxyliquit',
:user => 'john',
:password => '',
:connection_count => 2,
:evolve_schema_cautious => true
Note, that if you set :evolve_schema to false, you will get your behaviour
that no new table is added/removed/touched.
You will still get notified that a table is not available (due to creation
of a new Og-Class or even by subclassing of another class), but the DB
layout will not get changed.
The whole 'automagic' adding to the previous initialized Og entity comes
from the 'enchanting' of classes by using 'property' or 'prop_writer' etc.
With your idea (meaning the theory) of creating real database objects
(with different views possible on one real database) this could change
the whole Og library to something else (Og 2.0?).
I think James Britt said once in a discussion on the auto-enchanting, that
he liked it, because sometimes in his developing process he just wants to
make some objects persistant. Og provides him a way to do so, minimal
to his code.
(I hope I got that right, if not, sorry James)
I hope you can stay a little longer and possibly contribute more views,
ideas, theoretic and practic as well as academic knowledge.
Feel the love
More information about the Nitro-general