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