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.

Add more tests to excercise various features not supported on all platforms, such as the null-value/empty-string distinction or transactions.

It would be nice to be able to split of up the tests in user_dsn.t. Consider prompting for DSN in Makefile.PL, and then saving the result in a text file in the t/ dir, using EU::MM's prompt($message, $default);

Find people to test drivers for Sybase, MS SQL.

Object Mapping

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.

Driver Internals

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

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.

Driver Subclassing

Collect subclasses for other drivers, including Sybase, Informix, ODBC.

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.

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.)

Performance

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

Perhaps there's some way to generalize this to a define_named_query_sql method, but I can't quite see how to do this with the kind of syntax users might expect:

    $sqldb->define_named_query_sql( 'insert_foo' => {
      table => 'foo', columns => [ ... ], values => { },
    } );
    $sqldb->do_named_query( 'insert_foo', { column1 => value1 } );

A more practical approach to this could take the form of a limited interface such as do_bulk_insert, which would take an array of rows to insert:

  do_bulk_insert( table => foo, columns => [ ... ], values => [ {...}, {...} ] )
  do_bulk_insert( table => foo, columns => [ ... ], values => [ [...], [...] ] )

Such an interface could also support specialty options like statements_per_transaction => 100 in order to optimize performance on servers such as Oracle, where auto-committing one statement at a time is slow.

Additional Criteria

The Criteria subclasses are incomplete. Candidates include: Inequality, SubString, CaseInsensitiveSubString.

Consider enabling pure-Perl interpretation of criteria to allow post-fetch processing by Record::Set objects:

  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

DBIx::SQLEngine::ReadMe

cpanm DBIx::SQLEngine

perl -MCPAN -e shell
install DBIx::SQLEngine