1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
|
To Do List
Short term:
- Make RDBMSRules query driver for more stuff (max identifier length,
reverse engineering, etc.). This will require an active driver when a
new schema is created, however.
- Overhaul foreign key objects so that one relationship has one such
object, shared by two tables.
- Add constraints to output SQL for MySQL (InnoDB tables
will actually use them).
- Make sense of foreign key definitions for InnoDB tables in MySQL.
- Table update & delete.
- Update & delete "handles", to avoid having to regenerate SQL over
and over.
- Batch insert ?
- Add Alzabo::Runtime::Schema->clone method.
- allow defaults to be marked as functions ( NOW() ) so they're not
quoted in DDL SQL.
Medium term:
- reconsider MethodMaker's pre/post hooks and try to re-implement in a
more flexible/sane manner.
- Abort during Build.PL if supplied username/pw cannot connect to DB
(and try to test privs too). Suggested by Robert Creager.
- Output Dia XML.
- Make a tool to convert schemas from one RDBMS to another. This will
probably require user prompting because some things are unresolvable
without a loss of information.
- Add an Alzabo::Database class between the schema and table. This
will allow multiple databases in a schema (on multiple platforms
ideally) and allow you to do joins between these databases. This
probably raises all sorts of horrid transactional issues
I haven't yet thought of.
- Attempt to guess relationships when reverse engineering a schema
without foreign key information.
- More drivers & rules (Oracle, Sybase, Interbase, Solid, and so on)
- Integrate data validation into the code and schema creator in such a
way that Alzabo::MethodMaker can automatically create pre_insert and
pre_update methods.
- Expand regression tests for core API - SQLMaker, RDBMSRules.
- Give the options to save objects to disk in something a bit more
robust than a serialized object form. Eventually, Alzabo will spit
out some sort of XML.
Ongoing:
- Support 'feature probing' via the rules for user interface and to
determine whether to try to do things (like use transactions). This
is a broad idea and includes things such as returning a list of
possible column types to the user interface or having a flag for
supporting transactions.
- Robin Berjon suggested a single documentation 'page' that contains a
list of all the method and what objects they apply to. This exists
as Alzabo::QuickRef.
- Support any and all SQL, of arbitrary complexity. This is fairly
far along.
- Non-Mason interface(s) (curses, plain CGI)
|
