[orm-devel] Automatic table modufication (was: orm)

Diedrich Vorberg orm-devel@mailman.tux4web.de
Sat, 7 Dec 2002 02:59:23 +0100

Hi Ross, Hi Uwe and everyone else!

>> My next trick is to rewrite my packages using Python as Open Source, 
>> and set them free. 
Wow, I'm impressed!

>> I look forward to using orm in this process.
I hope orm will be able to meet your needs!

>Not to chase you away, or anything, but I think you might want to take a
>look at the GNUe project, as well as ORM: it's targetted more at the 'all
>singing, all dancing' sort of system your talking about. My understanding
>of Deidrich's vision/goals for ORM is that it's biggest virtue is in it's
>light weight - it's a membrane, not an entire layer. I'd be concerned about
>blowing it up with functions like database schema management  - it'd lose
>it's lightness, I'm afraid.

I can see the point Ross' is making here. ORM is supposed to be a
smart helper not a grown up middleware framework. However, depending
on how sophisticated the table modification mechanism is supposed to
be, it might not be very hard to write and it might not even outgrow 
its writer.

A module that contains all the dbclasses is basically a description 
of the SQL table's layout as a Python datastructure. If you'd write a 
program that would import that module, look at the model it describes 
and then creates the SQL to adapt the tables to that model you 
basically have got the thing you are looking for.

I'd not necessaryly code it directly into the datasource class but as 
a seperate module this could make sense, I think. The module might 
export a class like... er...

   from orm.model_manager import ModelManager
   mm = ModelManager(my_datasource) # you'll need a life connection

and then:

   # define or import my dbclasses...


   import beans
   mm.registerModule(beans) # the whole model in one module

and then:

   # just print warnings about modifications or raise exceptions if 
   # things won't work out


   # execute SQL commands to adjust the tables to the model
   # drop=1 will execute commands as MODIFY TABLE DROP COLUMN
   # drop=0 will not destroy any data, just warn (and maybe suggest
   # appropriate SQL statements)

I think it is important however, that this mechanism considers itself
subordinate to a programmer who knows his SQL basics. In other words,
it should be transparent what's going on. (Unless the programmer
deliberately turns that off) I could imagine a


method that will print the SQL statements correctTables() would 
execute allong with some commentary. Also there should be a mechanism 
to exclude tables from the process. An attribute in each dbclass will 

   class person(dbclass):
         manage_manually = 1

Programmers who use orm in the 'classic' way do not even have to know 
about this.

Uwe, if you feel like giving this a try I'll try to provide all the
help you need plus (this a good part of the deal :-) an account on an
old hp9000 workstation a couple of thousand miles away from you.

>Deidrich, you might even want to take a look at what they're doing - it's
>a different approach, but sometimes ideas can cross-fertilize. They're
>all young and energetic, too. ;-)

Yes, I will! I was looking at there website some time ago and didn't 
find any code. That was before I even knew Python and they really 
started. What I read on the page looks very promising.


           _..._                            Diedrich Vorberg
         .'     '.
        /  _   _  \                         http://www.tux4web.de
        | (o)_(o) |                         info@tux4web.de
         \(     ) /            .---.
         //'._.'\ \           /     \       Internet Dienstleistungen
        //   .   \ \          \.@-@./       und 'Consulting'.
       ||   .     \ \         /`\_/`\
       |\   :     / |        //  _  \\      Linux Rules!
       \ `) '   (`  /_      | \     )|_
     _)``".____,.'"` (_    /`\_`>  <_/ \
     )     )'--'(     (    \__/'---'\__/
      '---`      `---`