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

[Admin]

Hi all,
 
> >> My next trick is to rewrite my packages using Python as Open Source, 
> >> and set them free. 
> Wow, I'm impressed!
If I ever get it done I'll be relieved.

> >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...
>    mm.register(customer)
>    mm.register(address)
> 
> or
> 
>    import beans
>    mm.registerModule(beans) # the whole model in one module
> 
> and then:
> 
>    mm.checkTables(raise=1)
>    # just print warnings about modifications or raise exceptions if 
>    # things won't work out
> 
> or
> 
>    mm.correctTables(drop=0)
>    # 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
> 
>   mm.suggest()
> 
> 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 
> do:
> 
>    class person(dbclass):
>          manage_manually = 1
> 
> Programmers who use orm in the 'classic' way do not even have to know 
> about this.
> 

You've almost written it already!

> 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.
>

I might just take you up on this when I get some code happening.

Uwe.