----- Original Message -----
From: "John Sanda" <jsanda(a)redhat.com>
To: rhq-devel(a)lists.fedorahosted.org
Sent: Friday, May 24, 2013 11:02:03 AM
Subject: Re: Cassandra Schema Management Tool
On May 24, 2013, at 11:46 AM, Stefan Negrea <snegrea(a)redhat.com> wrote:
> Hello Everybody,
>
> Here are the design plans for the new Cassandra schema management tool:
>
> 1) A version table will keep track of the current schema version
> 2) The initial setup
> a) Will create:
> i)Initial RHQ admin user/password
> ii) RHQ keyspace
> iii) Schema versioning column family (=table)
> b) Once the initial setup is done, it will never run again
> 3) Everything else will be installed/updated via incremental changes:
> a) One change file per version change.
> b) Multiple changes can be bundled in a change file.
> c) The name of the change file will be used for database versioning
> purposes.
> d) If a change has already been applied it will not be applied again for
> the lifetime of the installation.
> e) If an incremental change fails, the upgrade process stops.
> f) The upgrade files will be in XML format, with a very simplistic XML
> Schema.
> 4) There will not be a single schema file for new installs.
> a) All installs will follow this incremental upgrade process.
> 5) All schema modifications outside of the schema manager will not be
> supported and are at risk.
>
>
> Starting with a simple and minimalist tool is the best solution (minimal
> set features, more robust). I expect the tool to evolve over time but if
> we keep things simple, then it will be to easier to maintain over time.
>
Why do we need xml?
I chose XML because it is a simple way to structure information. The goal is to have
multiple updates per file. For example, creating three column families in a single update
should be split into three smaller steps inside a big update file.
As an example:
001_Fancy_Update.xml:
- step: create CF A
- step: update CF B
002_Fancier_Update.xml:
- step: remove CF B
- step: create CF C
- step: create CF D
- step: create CF E
I am open to any other suggestions for file formats. JSON is not a good candidate because
there is no standard way to handle new lines. Any suggestions of something else that we
could use?
Stefan
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel