SQLAnywhere: fixup reals, implement preserve_case
[dbsrgits/DBIx-Class-Schema-Loader.git] / TODO
diff --git a/TODO b/TODO
index ca3138e..abb7495 100644 (file)
--- a/TODO
+++ b/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
+    - preserve_case mode for remaining backends
+  - 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
+    - normalize float/real/double data types in a most cross-deployment friendly
+      fashion, using float(25) as the double boundary where possible
+    - finish data_type tests for all DBs (DB2 and Informix left)
+    - 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
+    - add original => {} to all type info rewrites
+    - add common tests for preserve_case option
+    - correct handling of CamelCase names with numbers (eg. foo2Bar -> Foo2Bar,
+      foo2_bar)
+    - check rel accessors for method conflicts
+    - add an option to add extra code to Result classes
 
-Reminders to myself or whoever else ever looks in here...
+- 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?)
 
-SQLite needs some heavy refactoring, the subroutines are becoming to complex to understand easily.
-MySQL needs implicit FK support, I think.
-the base/use injection stuff needs error checking/reporting
-
-The whole things needs to be refactored so that we don't pollute Schema's namespace.
-
-  - Currently, the user's schema class ISA Schema::Loader ISA Schema::Loader::VENDOR ISA Schema::Loader::Generic ISA Schema, which means all of our methods and accessors in those classes end up in the final user "Schema" class.  The current hack to minimize that is that all the names are prefixed with "_loader" to avoid clashes.
-  - Ideally, user schema class ISA Schema::Loader, and that's it.  Schema::Loader only implements the methods that we need to export to the Schema class for later user (load_from_connection, tables, moniker).  Schema::Loader::VENDOR ISA Schema::Loader::Generic, but they have a new() routine and instantiate an object which does the Loading.  Schema::Loader passes them the its own class name (the user schema class) so that they know what namespace to target the loading operations at.
-
-After all that, consider:
-   If local column is UNIQUE or PK, use has_one() for relation?
-   Re-scan relations/tables after initial relation setup to find ->many_to_many() relations to be set up?
-   Check NULLability of columns involved in the relationship, which might suggest a more optimal non-default -join-type?
-
-...
+- 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
+    - preserve_case mode
+    - domains
+  - DB2
+    - data_type tests
+    - table/column comments
+    - introspect on_update/on_delete/is_deferrable
+    - introspect view SQL
+    - preserve_case mode
+    - domains
+  - Oracle
+    - table/column comments
+    - introspect on_update/on_delete/is_deferrable
+    - introspect view SQL
+    - preserve_case mode
+    - 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
+    - preserve_case mode
+    - table/column comments
+    - introspect on_update/on_delete/is_deferrable
+    - introspect view SQL
+    - domains