[orm-devel] Automatic table modufication (was: orm)
07 Dec 2002 14:06:04 +0000
> >> 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...
> 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.
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.