On 9/27/01 3:27 PM, "Fedor Karpelevitch" <[EMAIL PROTECTED]> wrote:
> I think, a better way to handle these would be to add support for > "including" one schema into another. maybe some <include> element or > something... FOr example a turbine app would just "include" turbine schema > into it's schema. that would remove the need for nasty hacks when you have > to create alias for turbine_user in your own schema... > Any ideas on what would be most kosher way to do this? I personally don't like this method as you can't really take advantage of an <uptodate> task for rebuilds. I think separate schemas are better for maintenance. Even with the changes I'm proposing you could still do that if you wanted but I wouldn't recommend it. And I certainly would be against making that the method that is employed in the TDK. If you create subsequent schemas you must edit and fart around with the main schema that includes all other schemas. By using a fileset you can process 1 or 10 in the same fashion. > fedor. > > ------------------------------- > Amicus Plato amicus Aristoteles magis amica veritas > >> -----Original Message----- >> From: Jason van Zyl [mailto:[EMAIL PROTECTED]] >> Sent: Thursday, September 27, 2001 12:20 PM >> To: [EMAIL PROTECTED] >> Subject: Torque and <filesets> >> >> >> Hi, >> >> I am trying to provide an easy way of dealing with multiple >> databases in the >> TDK and I would like to add the ability to the torque task of >> dealing with >> a set of xml torque schemas. >> >> The tasks would work with their current syntax accepting xmlFile as a >> parameters, but if that attribute is not present than a >> <fileset> of xml >> torque schemas will be processed. >> >> For now I am interested in changing the following tasks: >> >> TorqueCreateDatabase >> TorqueObjectModelTask >> TorqueSQLTask >> >> I would also like to change the TorqueSQLTask to produce a >> small table that >> maps the SQL file to the database it should be inserted into. >> I would than >> make another task using the <sql> task as a base that would >> take this little >> table and slot each SQL file into the appropriate database. >> >> I am thinking that a project may potentially have several xml >> schemas, as >> tambora does, and that it might be better to keep them >> separate so that an >> <uptodate> task can be used to automate rebuilds in the >> future. In tambora >> we like to keep the turbine schema in one database and the >> tambora schema in >> another. But the changes the tasks won't affect current >> operation: if you >> use one schema than that's fine. >> >> I'm trying to find an easy way to maintain the data model >> given the use of >> one database or many. Again these changes won't affect >> current use, and I >> primarily want these changes so I can simplify the sample app >> initialization >> and deployment in the TDK. >> >> I'm off to bed now :-) >> >> -- >> >> jvz. >> >> Jason van Zyl >> >> http://tambora.zenplex.org >> http://jakarta.apache.org/turbine >> http://jakarta.apache.org/velocity >> http://jakarta.apache.org/alexandria >> http://jakarta.apache.org/commons >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
