Cassandra branch merging into master in the next couple of hours (dbsetup thread)

Jay Shaughnessy jshaughn at redhat.com
Fri May 31 15:24:51 UTC 2013


On 5/30/2013 11:23 PM, John Sanda wrote:
> 2) dbsetup issues
> As I pointed out during the demo, the only time you really need to apply schema changes from the dbutils module for your dev-container is to apply updates to an existing db. There is no need to install a new schema since this will be done for you when you run rhqctl install; consequently, I have made the following changes in dbutils:
>
>      * Cassandra schema changes are disabled by default
>      * You have to set -Dstorage-schema to activate Cassandra schema changes
>      * Cassandra schema changes are only applied when either the dbsetup-upgrade
>        or dbreset property is set.
>
> I think this will alleviate a lot of the problems people have encountered. Unlike postgres, we don't have a storage node up and running until we build the dev-container and then explicitly install the storage node. It therefore does not make much sense to try to apply schema changes to C* when running dbsetup.

I can't say i really like this approach.  To me the storage DB is an 
extension of the RDB. Together they form the persisted store for RHQ.  
Performing setup on just the RDB part would leave you in an inconsistent 
state.  The only time it makes sense is when the Cassandra DB is not 
installed (i.e. the first build).   If Cassandra is installed and not 
running then the dbsetup should likely fail.  I don't like that we now 
have another property we must set.

And maybe I'm in the minority, but I dbsetup *often* in my dev 
environment.  I *do* want this to recreate my C* schema.

I would have preferred that we just look to see if the rhq-storage 
directory exists, and if not just ignore the C* portion of dbsetup.






More information about the rhq-devel mailing list