Firstly, let me just say that this is so cool. Finally a database independent way of managing schema creation. I'd like to throw out an idea about a way that would (of course) benefit me personally, and many small software developers who have to manage database upgrades as part of their ongoing support of applications.
My idea is firstly to allow the xmlschema to allow the modification of, and deletion of existing tables, eg
<table name="abc" method="drop">
Secondly, a version control table that could be stored in the database that would allow schemas to be applied sequentially, in the correct order. As an example, we would have a version embedded for each table
<table name="abc">
<version="1"/>
......
</table>
then the next time we come around with an update,
we could embed something like
xmlschema could read the Version in the database, and reject the update if the version or higher was already installed or the required version was incorrect.
Put together, these features would allow cumulative, database-independent schema patching to occur.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The ability to drop tables and objects is a nice idea, and probably not to difficult to implement.
The version control concept is intriquing. I'm currently contemplating upgrade management methods, and that fits right in. Particularly since I'd like to make schema management as automated as possible.
Non-trivial, though, with the current architecture, which creates the SQL for the entire schema build in one pass ("parse") and executes it in a second ("execute"). I may need to a "pre-parse" pass that looks at the database to determine whether to create or upgrade. In this case, going to a meta version-control table might make sense.
Rich
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Firstly, let me just say that this is so cool. Finally a database independent way of managing schema creation. I'd like to throw out an idea about a way that would (of course) benefit me personally, and many small software developers who have to manage database upgrades as part of their ongoing support of applications.
My idea is firstly to allow the xmlschema to allow the modification of, and deletion of existing tables, eg
<table name="abc" method="drop">
Secondly, a version control table that could be stored in the database that would allow schemas to be applied sequentially, in the correct order. As an example, we would have a version embedded for each table
<table name="abc">
<version="1"/>
......
</table>
then the next time we come around with an update,
we could embed something like
<table name="abc">
<version="2">
<requires_version="1">
.......
</table>
xmlschema could read the Version in the database, and reject the update if the version or higher was already installed or the required version was incorrect.
Put together, these features would allow cumulative, database-independent schema patching to occur.
Mark,
The ability to drop tables and objects is a nice idea, and probably not to difficult to implement.
The version control concept is intriquing. I'm currently contemplating upgrade management methods, and that fits right in. Particularly since I'd like to make schema management as automated as possible.
Non-trivial, though, with the current architecture, which creates the SQL for the entire schema build in one pass ("parse") and executes it in a second ("execute"). I may need to a "pre-parse" pass that looks at the database to determine whether to create or upgrade. In this case, going to a meta version-control table might make sense.
Rich