> > I'm not sure you need OOP for this.
> I suspect you're correct Alan, but as I'm using this an a learning
> exercise for the language it seemed too good an opportunity to miss
That's fine so long as we understand why you are going down the OOP route.
> can relate a table to an "object" in my head quite easily - just need to
> know how to do it in Python...
OK, So if you can conceptualise a table what are the operations
you would perform on it?
It sounds like you want to
- add columns - from a definition file/document?
- generate DDL based on current structure?
- export a definition document?
- Maybe autopopulate the definition from a given database connection?
So the use case nmay be something like:
Create a table connected to the old database.
The table sucks up the metadata from the database and auto-populates
itself with columns(which might be another class with name, type,size type
details)
Create a new Table object targeted at the new database (which might not exist
yet?)
If the table can't auto-populate then feed it the oold table object which it
queries for
a description.
The new table then populates its own definition.
Finally get the new table to generate the DDL and populate the new database.
You might want different table classes each based on different databases,
so they populate themselves based on the specific meta language and spit
out a common description format. They cn then generate their own dialect
of DDL too...
Does that seem like a starter?
But really, when working with objects it helps to sit back and think through
how you want to use them from the outside rather than thinking about what
they look like inside. That way the internals will reflect what's actually
needed
for the usage rather than some random model of what might be needed.
HTH,
Alan G.
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
