On Fri, Feb 22, 2008 at 5:28 AM, Daniel López <[EMAIL PROTECTED]> wrote:
> I added initial support for the filtering of "tables" (quoted as they > can be tables, views or other table types). I simply added a new > parameter to the DatabaseToDdlTask and passed the parameter until it > reaches the JDBCModelReader, where the filter is applied. Null or "" > string means all the tables are processed. > > I was not sure if we would want to use a filter when altering the > tables, so I simply passed a null in all the calls that read the model > to later alter it. > > I used "tableTypes" parameter as model and followed more or less the > same conventions. That means I also did not "log" anywhere the filter > value... I guess having it explicitely written in the ant task might be > good enough, even though spitting out the filter being used in debug > mode might be useful, in case some people pass the filter value as > property or can read just the output and not the task configuration. > > Before adding it to the JIRA issue, I'm sending it to verify the patch > format is ok with you. I created it with the Eclipse, Team -> create > patch utility. Thanks for your work ! The patch format looks fine, the Eclipse patch function creates unified diff patches which are perfect. > I did some tests with a DB of mine and everything works as expected, are > there any "formal" tests you use for such contributions? The patch is > quite simple, but I'd hate to break other parts ;). It depends. There are no formal or unit tests for Ant tasks, but if it also contains library (API) functionality, then a few unit tests can't hurt :-) cheers, Tom
