[Nitro] og regarding legacy apps table hints

[Robert Wagner]

> There are or at least there will be ways to express foreign keys and
> indexes, as well as map names of fields and tables etc. There will be
> more useful parts (like autodate) for objects to be managed for
> persistence to include when needed. What's that special usefulness that
> your pure text version provides?
> 
> If you need this kind of definition to be somehow abstract, one should
> be able to write a text to Og Ruby code translator pretty easily and
> then one could convert the above text to above code for run-time
> evaluation without great pains.
> 
> So again I making a question what's this all for? What do we gain by
> adding an extra layer needing conversion?
> 

your right. sorry. maybe you don't need it. it's just me the swinging man, who
thinks to need it. cause i'm switching environments that often needs conversion.
a simple to parse metafile is quite usefull ... and think of comparing
versions - every
line is a property...

> What I can see that we're losing by using pure text (ini-file based or
> not) data definition mini-language is the ability to use
> turing-complete, working, easy, simple and useful full language to
> describe a bit more complex issues. And do so even without having text
> to code to datastructures conversion library source code, just by
> extending where Og left.
> 

this is a strong argument. but i thought of the textversion as an
*option*, then
as a subset (namely the most often used rdbms features) of
possibilities. and yes:
some converter should be easily done by myself :)

  -robert

> Should you need to write to logfile every time object's accessor is
> used, you're free to define your own "property" method for definition
> language inside Ruby. Not to mention Og already supports Aspect Oriented
> way to inject code.
> 
>     - Aleksi
> 
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>