Version 0.1.1 Beta (April 8, 2003)
Version 0.1.2 Beta (April 15, 2003)
- Miscellaneous bug fixes and documentation improvements
Version 0.2.0 Beta (August 26, 2003)
- Added unique and "all-or-none" constraint capabilities. Both constraint types can
be applied against one or more fields. All-or-none constraints can be used to validate data where either all
fields defined for the constraint should be given or none should be given. For example, if you have
several address fields defined, you could define an all-or-none constraint on street, city, country,
and postal code, so that if any are given they must all be given.
- Upgraded code to not use any depricated methods.
- Upgraded the documentation and sample test cases to reflect the enhancements.
Planned Future Enhancements (as of May 16, 2004)
Currently performing analysis for a version to be released sometime before the end of 2004 that will contain the following enhancements:
If you are interested in seeing any other enhancements in a scheduled release or would like to report any bugs,
please contact the author.
- The database connection logic will be enhanced to read the connection information from an XML file
instead of from hard coded data in a java file. Aside from the runtime flexibility advantages
(like being able to change the database password without having to re-compile the application),
this will allow for a downloadable binary version of the application.
- A downloadable MySQL database pre-populated with startup data required for any
JFileChecker database will be available for download. Combined with the previous enhancement this
should make for a nearly "out of the box" release.
- What it means for a data record to be "bad" will be more flexible by categorizing the record validity checks into levels
(4 by default being INFO, WARN, ERROR, and FATAL). Users will be able to configure as many levels as desired in the database.
For example, you may just want to know if a record has a Birth Date < 1/1/1920, and so
you can rank this check as "INFO". However, a check that ensures a crucial field is not empty could be ranked as "FATAL".
The output file currently created can be prefaced with such prefixes for easier error classification.
- An optional output file being the original file with "bad" records stripped from it will be available to
be created with this release. Users can create this output file of "good" records by choosing the overall
"level" (for example, "ERROR") whereby records at this level and above are simply not included.