> > Hi Jon,
> >
> > I would like to make another suggestions here.
> >
> > I created a new datastructure (called AppData) for my template based
code
> > generation. The reason for this is to be able to handle stuff that
> > DatabaseMap was not designed to do - for example ON DELETE CASCADE. I'm
> > also thinking to add some other features to this class in future. One
of
> > them woud be to add default values to columns so that the generated OM
> > classes can be initialized in the constructor.
> >
> > There is currently a copy of this under downloads from
www.opticode.co.za
> >
> > I propose we move the entire Torque code to AppData. This way we can
evolve
> > the datastructure of the Torque project without fear of breaking
something
> > important in Peers. If everybody is happy with this I'll do most of the
> > work I.e. SQLToAppData, JDBCToAppData, [XMLToAppData is already done]
and
> > AppDataToSQL [OM Generation is already done with templates - see the
> > download] .
>
> Can you explain a little further. Are you proposing to move the source
> of all generation to AppData? As opposed to it being coming from
> an XML description? Is AppData a replacement for DatabaseMap?
>
> jvz.
>
Sorry, I might not have been very clear. Basically my problem is that I
want DatabaseMap to have some richer functionality to create SQL Schemas, OM
Classes, etc. DatabaseMap has the primary function of holding information
about the database for Peers, and I think we're using it in a way it was not
originally designed for.
I created a compatible set of classes AppData/Table/Column to replace
DatabaseMap/TableMap/ColumnMap for generation code. At the moment they look
very similar - I also build them from an existing Torque XML file.
I would like to move DatabaseMap as the internal Datastructure for Torque to
AppData. People using Torque should not even notice the difference. It is
only an internal change to allow for better future development.
The reason I propose this move is that we can from here on evolve AppData to
better suit Code Generation and not interfere with the DatabaseMap classes.
Some of the first things I see in here is stuff like ON DELETE CASCADE and
possible default values for columns.
I also have plans for some basic actions (I hate repetitive hand coding
tasks). These definitely does not belong in the DatabaseMap datastructure
:-)
~ Leon
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]