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] .
~ Leon
>Jon Stevens wrote:
>
> Ok,
>
> I made a fatal mistake when I wrote that .sql parser. Essentially it all
> boils down to me not realizing that you can change the name of the foreign
> key column that references to another table...for example:
>
> FOREIGN KEY (OBSERVED_ID)
> REFERENCES SCARAB_ISSUE(ISSUE_ID),
>
> instead of what i thought was only possible:
>
> FOREIGN KEY (ISSUE_ID)
> REFERENCES SCARAB_ISSUE(ISSUE_ID),
>
> I have figured out that this problem isn't easily fixable. It is easier to
> fix by re-working the parser. Here is the details on how to do it. I think
> it will actually turn out to be a much cleaner set of code as well.
>
> First, read in the entire file into a Vector or String[], one line from
the
> file per entry in the Vector. The reason is that you will need to loop
over
> the data multiple times (3-4 i think).
>
> Next, loop over the Vector and generate all of the TableMap's. Then, loop
> over the Vector again and generate all of the ColumnMap's. Then, loop over
> one last time and use the generated information to build up all the
> relationships in the ColumnMap's.
>
> The problem with the current approach is that it is a one pass parser and
> prevents you from being able to make the above association because the
data
> for it may or may not exist yet.
>
> That should be much cleaner code and will also allow you to more easily
> handle the case above. You should use the existing parsing code to help
you
> loop over the lines.
>
> Anyway, I'm pretty much documenting this as something I need to fix, but
if
> any one of you want to take this task on, please feel free. I don't have
the
> time right now to fix it, but will eventually.
>
> thanks,
>
> -jon
> --
> http://scarab.tigris.org/ | http://noodle.tigris.org/
> http://java.apache.org/ | http://java.apache.org/turbine/
> http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
> http://www.collab.net/ | http://www.sourcexchange.com/
>
>
>
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
> Problems?: [EMAIL PROTECTED]
>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
