[Nitro] og regarding legacy apps table hints
robbie.wilhelm at gmail.com
Tue Aug 16 16:27:43 EDT 2005
> 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
as a subset (namely the most often used rdbms features) of
possibilities. and yes:
some converter should be easily done by myself :)
> 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
More information about the Nitro-general