> -----Original Message----- > From: Jason van Zyl [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 27, 2001 12:39 PM > To: [EMAIL PROTECTED] > Subject: Re: Torque and <filesets> > > > 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.
We are trying to solve slightly different problems, I guess. I am talking about a case when some schema is an integral part of a bigger schema. An example is turbine schema which is a part of a turbine app's schema. In this case, I guess, it would be valuable to be able to "include" turbine schema into app schema, so they are considered to be the same db. This would not let you provide a wrong FK from your table to TURBINE_USER and such and would not require you to do any cut-and-paste which is never good. This also reflects dependencies correctly - app schema depends on turbine schema. So when you do an uptodate check you would be able to (and should to be correct) also walk down the deps - id app schema is updated it needs to be regenerated, if turbine schema is updated - both need to be regenerated. What you are trying to do is to process several independent schemas in one shot. It may have it's valid applications, but it's a different case... fedor > > >> -----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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
