-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathTODO
83 lines (80 loc) · 4.8 KB
/
TODO
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
80
81
82
TODO List:
* Test connectivity with ODBC driver (using psqlodbc for now).
- Connection string: "odbc://DSN=dbmig_ex1;foo=bar;baz=quux"
* Change db_specific.cpp/hpp to be keyed on SQL dialect rather than DB type.
- This is because something like generic like "ODBC" type might involve
possibly-different dialects underneath.
- Or maybe move as much as possible to "standard" SQL?
* Add tests for when upgrade/rollback scripts don't have the magic separator.
* Fill in timing information when running scripts.
* Add tests for scripts in non-UTF-8 encoding.
* Add support for test DB connections in configure step, and use these in
integration tests.
* Add DocBook sources and integrate with autotools.
* Expand the check command to work with situations where a repository has had
old upgrade scripts compressed into a single install script.
* Add libdbmigtest/data/ to Makefiles so that it is included in "make dist".
* Implement create-unversioned command using DFS search on filesystem.
* Implement purge command.
* Add a -s/--simulate switch to print what *would* happen.
* Add integration tests that will use a real database environment to run tests.
- Should there be a test/ sub-dir in libdbmig for genuine unit tests of the
internal classes, and use libdbmigtest only for integration tests on the
public API?
* Write unit tests that cover globbing functionality in script_dir.
* Clean up repeated option-parsing code in dbmig.cpp.
* Move libdbmig includes to a dbmig/ subdir, e.g. #include <dbmig/migrate.hpp>
* Link dbmig to libdbmig as a shared library.
* Think about approach to Java / .NET bindings.
Completed:
* Neatly cater for libraries being named differently on Windows.
- Use conditional in configure.ac based on $host (feels a bit hackish).
* Ensure cross-compiling for win32 works
- Need to either link EVERYTHING statically against libgcc and libstdc++ or
provide libgcc_s_sjlj-1.dll and libstdc++-6.dll in $(prefix)/bin.
Can use the -static-libgcc -static-libstdc++ LDFLAGS options.
- What about libwinpthread-1.dll? Why is this required?
- ./configure --host=i686-w64-mingw32 --prefix=/usr/i686-w64-mingw32
* Change all console logging in dbmig to be Unicode-aware.
- Accept Unicode strings in UTF-8 format: http://www.utf8everywhere.org
* Make libdbmig fully Unicode-aware (even on Windows):
- All filesystem interaction (script_dir).
- All file I/O (script_stream). Swap std::istream for nowide::fstream.
* The script number (script.XXXX) should be recorded as a numeric, rather than
stored with any zero-padding. Prefer numeric and always parse to this.
* Set up dbmig.xsco.org website, and github hosting.
* There is a bug in the translation between repository and script_dir.
repository::upgrade_scripts() expects the from version to be the starting
version, i.e. that already deployed. But in script_dir::range(), the from
version is expected to include upgrade scripts. If we have an install script
which has the same version as an upgrade script, will this break?
This bug will not manifest when rolling back, since the scripts are versioned
after the incumbent changelog version in that scenario.
* Add tests for repository::upgrade_script_at().
* Add globbing support to script_dir's search, so that only *.sql is considered
in scope, and other files are not flagged for not being version-parseable.
* The changelog table's script_path field should contain a relative path
(relative to the repository's install/upgrade directory).
* Add a "check" command (or different name) to attempt to identify whether the
chosen repository has scripts that are compatible with what is in the
changelog of a target database
- The output highlight should specific missing or not-deployed scripts
- What should the behaviour be when old upgrade scripts have been replaced
with a new install script in the repo but the DB has older upgrade history?
* Rename changelog table to dbmig_changelog, to avoid possible name clashes.
* Implement migrate command fully.
* Implement method that performs roll-back.
* Add class/functions to execute script statements, and then write a changelog
entry in a single transaction.
* Separate changelog into changelog_table (takes a SOCI session) and changelog
the service, which is a class that takes conn string and changeset.
* Make any command that changes the database ask for confirmation before
proceeding, unless a -f/--force flag has been specified.
Replace --simulate option with --force too.
* Upgrade from SHA1 hashes to SHA256.
* Implement SHA256-hashing algorithm for scripts applied. Use crypto++ lib.
Make sure that the digest calculated matches what sha256sum would say.
* Write unit test in repository_test to check that noncontiguous scripts are
correctly identified.
* Write iterators/streams for deployment actions.
* Use SOCI library for DB access.