preserve local changes to generated files by default (still needs tests)

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

diff --git a/TODO b/TODO
index ca3138e..00330a2 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,18 +1,27 @@
 
-Reminders to myself or whoever else ever looks in here...
+immediate stuff for 0.04:
+--------------------------
 
-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
+avinash240 wants a rescan method to pick up new tables at runtime
 
-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.
+support multiple/all schemas, instead of just one
 
-After all that, consider:
+support pk/uk/fk info on views, possibly.  May or may not be a sane thing to try to do.
+
+Fix up ResultSet Manager / Methods / etc stuff.  May require some work in the
+main DBIx::Class first.
+
+SQLite needs some heavy refactoring, the subroutines are becoming too complex to understand easily.
+
+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.
+
+Relationship stuff:
    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?
-
-...
+   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?)
+   ...