NAME
    DBIx::SQLEngine::Docs::ToDo - Tasks, ideas, and bugs

TO DO
    There are a number of things that could be done to improve this module.

  Distribution

    Consider bumping the version number; the leading zero may deter some
    potential users by suggesting a less complete package.

  Tests

    The test scripts are incomplete and really ought to exercise much more
    of the public interface. Specific things to add to the test include:

    - Test for inserting, updating and selecting nulls, including "is null"
    test.

    - Test new transaction code.

    Figure out how to best write tests for features not supported on all
    platforms, such as the null-value/empty-string distinction or
    transactions.

    Consider prompting for DSN in Makefile.PL, and then saving the result in
    a text file in the t/ dir.

      my $value = prompt($message, $default);

  Internals

    How do we compensate for different versions of a database system? For
    example, newer versions of MySQL support a number of features that the
    old ones don't. Perhaps we should attempt to detect this, and rebless
    into an appropriate subclass.

    The handling of primary keys in Schema::Table and Schema::Column is not
    yet correct. The Record classes could also use a review to ensure
    primary keys are handled correctly throughout.

    The column-information retrieve in DBIx::SQLEngine::Default should be
    using DBI's type_info methods.

    Consider centralizing logging interface by making 'DBI', 'SQL' arguments
    to general function, or using log4perl.

    Consider becoming a subclass of DBI via RootClass and DbTypeSubclass,
    rather than using composition via DBIx::AnyDBD. This is somewhat
    attractive: it might run faster by eliminating a layer of delegation,
    and it would facilitate separation of the DBH and STH methods. The
    downside is loosing the flexibility of composition: if someone had their
    own DBI subclass, we could dynamically wrap around it if using
    composition, but it might be harder to dynamically inherit from it.
    There's also a certain degree of inertia in favor of not changing it.

    Determine the right way to handle the multiplexing drivers,
    DBD::Multiplex, DBIx::DBCluster, and DBIx::HA, given that they may
    reconnect to a different server in mid-stream.

    Determine the right way to code the driver traits currently stored in
    Mixin::*.

    Consider simplifying reuse of SQL statements in similar situations, such
    as inserting hundreds of rows. (See the PERFORMANCE entry in the
    SQL::Abstract manpage.)

  Database Subclasses

    Collect more subclasses: Sybase, Informix, ODBC, others.

    Review DBIx::Compat; it seems like this information should map fairly
    directly to candidate methods and subclasses.

  Additional Criteria

    The Criteria subclasses are incomplete. Candidates include: SubString,
    CaseInsensitiveSubString, NumericEquality, NumericInequality,
    StringInequality.

    Consider enabling pure-Perl interpretation of criteria:

      package DBIx::SQLEngine::Criteria::Equality;
  
      sub inverse { 'DBO::Criteria::Inequality' }
  
      # $flag = $crit->matches( $record );
      sub matches {
        my ($crit, $record) = @_;
        return ($crit->value( $record ) eq $crit->{'value'}) ? 1 : 0;
      }

SEE ALSO
    the DBIx::SQLEngine::ReadMe manpage

