[Nitro] og regarding legacy apps table hints
robbie.wilhelm at gmail.com
Tue Aug 16 14:46:18 EDT 2005
2005/8/16, TRANS <transfire at gmail.com>:
> If a file were to be used, then it should be a YAML file. YAML is
> universal, INI files are more windows centric.
> The descriptor-file design is NOT a good one. It's adding yet another
> layer of duplicate information --far from DRY. The best way is either
> the Og way or the ActiveRecord way. I.e. either the OO system
> specifies the data structure, or the relational backend does. There's
> no need for a third way to tell both of them how to be.
i disagree. of course the pure og way doesn't need that (in theory). but even
if you don't want to use it for existing tables you *should* give hints about
creating indexes and stuff. AR on the other side can't read every information
as metadata from the db. think about foreign keys, that simply don't exist in
mysql (myisam) tables. the question is: where is this information stored?
the classfile is quickly clustered with this stuff. so i like the
*option* for saving
that in an external file...
> Such systems
> (and there are plenty) are a pain.
i agree, most *existing* systems are pain :)
> And I like that Og will be able to
> support the ActiveRecord way too; so it will have the best of both
this is what i have in mind. feel good with *one* API and use it everywhere
> FYI, if you are concerned about SOC (Seperation of Concerns), I'm with
> you. But that can be done in the OO system too. To do so in Og, simply
> build your classes as normal (don't consider the DB), then afterward
> create seperate modules to extend the classes with the porper DB
yes, that could be a way for the separation.
>This makes for a vry elegant and clean design (with only a
> slight but worthy sacrifice to DRY) I've talked to George about this
> and he knows it something to solidly support in Og.
> Nitro-general mailing list
> Nitro-general at rubyforge.org
More information about the Nitro-general