[Tutor] "Object designer" applications - are there any?

[Flynn, Stephen (L & P - IT)]

Yup - sounds more like what the final version of my little project will
do. 

 

At the moment, I'm more interested in taking each specific database's
version of it's DDL and converting it to an Oracle version of that DDL,
so initially it's not much more than a text converter which reads in
text describing Sybase tables and spits out DDL describing Oracle
tables.

 

I'll spend a day working out my objects, their methods and properties,
get that all nailed and begin the fun and games in translating my
headspace into Python.

 

I'll inevitably hassling you people as and when I get stuck or want some
advice on the best way to proceed, so I guess by the end of it, you'll
all be as sick of this as I will be. Share the misery...

 

 

S

 

________________________________

From: ALAN GAULD [mailto:alan.gauld at btinternet.com] 
Sent: Friday, August 05, 2011 4:34 PM
To: Flynn, Stephen (L & P - IT); tutor at python.org
Subject: Re: [Tutor] "Object designer" applications - are there any?

 

 

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

 

Click here
<https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg==
1AVZPhIxlsZ4UqhB+qagH4nqPtDbwPBBNdVeTFI5G433hQ==>  to report this email
as spam.



This email and any attachment to it are confidential.  Unless you are the intended recipient, you may not use, copy or disclose either the message or any information contained in the message. If you are not the intended recipient, you should delete this email and notify the sender immediately.

Any views or opinions expressed in this email are those of the sender only, unless otherwise stated.  All copyright in any Capita material in this email is reserved.

All emails, incoming and outgoing, may be recorded by Capita and monitored for legitimate business purposes. 

Capita exclude all liability for any loss or damage arising or resulting from the receipt, use or transmission of this email to the fullest extent permitted by law.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20110808/4b444c9a/attachment.html>