Fix =head level for some constructor options.

[dbsrgits/DBIx-Class-Schema-Loader.git] / TODO

- General
  - High Priority
    - clean out RT queue
    - introspect views and make proper ResultSource::View classes with defining SQL
    - encode loader options in Schema.pm
    - introspect on_update/on_delete/is_deferrable
  - Low Priority
    - support multiple/all schemas, instead of just one
    - support pk/uk/fk info on views, possibly (materialized views?)
    - remove deprecated ResultSetManager stuff, rewrite using current features
    - Refactor RelBuilder so that it doesn't require a live mostly-built
      DBIx::Class::Schema, so that other modules (SQLT) can use it easier.  And
      then when/if we get there, break it out as a seperate distribution with a
      new name.
    - support for user-defined-types as Schema deploy hooks
    - generate a schema accessor which stores which SQLT type it was loaded from
    - add a settable 'on-behalf-of' version tag (for catalyst model)
    - inject a table2moniker function into the schema
    - support coderef for relationship_attrs
    - common tests for table/column comments
    - optimize queries
    - remove extra select for _filter_tables
    - option to promote non-nullable unique constraints to PK (prefer int
      columns when more than one) (RT#51696)
    - figure out how to represent Informix 'DATETIME YEAR TO FRACTION(5)' in a
      way that SQLT will like
    - support domains (aka custom data types) as a Schema deploy hook
    - add hashref form of generate_pod to control which POD is generated
    - add hashref form of components to control which components are added to
      which classes
    - check rel accessors for method conflicts
    - add an option to add extra code to Result classes (maybe...)
    - redo in-memory schema as an @INC coderef rather than temp files
    - add option to filter out views
    - support columns with names like "ro'd p/n" in MSSQL

- Relationships
   - Re-scan relations/tables after initial relation setup to find
     ->many_to_many() relations to be set up
   - While scanning for many-to-many, scan for implied rels as well (if
     foo->belongs_to('bar') and baz->belongs_to('bar'), does that impliy
     foo->might_have('baz') and the reverse?)

- Backends
  - SQLite
    - table/column comments
    - introspect on_update/on_delete/is_deferrable
    - introspect view SQL
  - MySQL
    - table/column comments
    - introspect on_update/on_delete/is_deferrable
    - introspect view SQL
    - domains?
  - Pg
    - introspect on_update/on_delete/is_deferrable
    - introspect view SQL
    - domains
  - DB2
    - table/column comments
    - introspect on_update/on_delete/is_deferrable
    - introspect view SQL
    - domains
  - Oracle
    - table/column comments
    - introspect on_update/on_delete/is_deferrable
    - introspect view SQL
    - domains
  - Sybase ASE
    - table/column comments
    - introspect on_update/on_delete/is_deferrable
    - introspect view SQL
    - domains
  - MSSQL
    - table/column comments
    - introspect on_update/on_delete/is_deferrable
    - introspect view SQL
    - computed column support
    - domains
    - Optimization
      - use one query for whole table instead of query-per-column in _columns_info_for
      - use placeholders when available
  - SQLAnywhere
    - table/column comments
    - introspect on_update/on_delete/is_deferrable
    - introspect view SQL
    - domains
  - Firebird
    - table/column comments
    - introspect on_update/on_delete/is_deferrable
    - introspect view SQL
    - domains
  - Informix
    - data_type tests
    - table/column comments
    - introspect on_update/on_delete/is_deferrable
    - introspect view SQL
    - domains