To HSQLDB or not to HSQLDB

[Henry Widman]

The migration instructions for Fisheye/Crucible recommend using an external DB (Oracle, SQL Server, mySQL, etc.) instead of the built-in HSQLDB DB. I'd like to keep things as simple as possible and use the built-in DB. Is that really not a good idea? We will only have about 8 users accessing the tools and not they will not be using the tools all that often. Also the dataset would not be particularly large (80 MB or so).

Would it really be problematic to stick with HSQLDB?

Thanks,

Henry

[Nic Brough -Adaptavist- · Accepted solution]

Yes. Move. Hsqldb can fail catastrophically without warning.

[J. Caldwell]

+1 to Nic's comment

[J. Caldwell]

It is very problematic. If you do not mind losing all data in your instalation, by all means, use HSQLDB. If you want reliability, recoverability and it will be a production installation, use a real database. Atlassian says that HSQLDB is for non-production use, and they mean it.

A mysql database is very simple. It takes about 10 minutes, 20 if you've never done it before, to set it up and FECRU does the rest.

It takes about 5 minutes to create a simple DB backup script.

All of that assumes you have Google and space.

[J. Caldwell]

Henry,

Sorry...I missed the response. I don't know SVN really, so I would need to rely on others. Sorry.

[Henry Widman]

OK. I think I will just have to play around with things and find out what works. I think I'll let this thread go off to the great bit bucket in the sky (or should I say cloud) and if I need help I will dive back in with a new question.

Thanks for the help all.

[Nick]

Are you using the file:/// protocol to connect FishEye to your svn repos ? If so, no auth element is needed.

Also, the config.xml will have a <database> element where you will need to have the correct database username and password for the jdbc url defined there too.

[Henry Widman]

The thing with the file:/// protocol for pointing to the Subversion repository is that I have tried to use that when running Subversion commands (we're using a Windows Server environment) and those commands just didn't like that format, so I'm a little leary in using that for setting up Fisheye/Crucible, but I just may just give it a try. If I do need to give a username and password it would be for the Subversion admin I would suppose and not the OnDemand admin as the migration page says.

I didn't see anything in the migration pages regarding a database element in the config file, but I will look for that.

Thanks.

[J. Caldwell]

Henry....what's the last question?

[Henry Widman]

J.,

The last question was in regards to updating the config.xml in the Fisheye/Crucible backup to prepare for a restore operation (to initially load the F/C database). In the migration page it says if your not using the file:/// protocal to point to the new Subversion instance then you must enter credentials via auth username and password and these should bethe OnDemand admin credentials (see below). Should these credentials not be the admin for Subversion? I could see where F/C would need the credentials for JIRA OnDemand (which we still are using since it will be linked to it), and also for the F/C external database for that matter, so you would think all those credentials would need to be given in the config file.

"<auth username="" password=""/>Enter the OnDemand administratorusername and password. If you use the file protocol (file:///), you can leave the username and password blank."

I may be overthinking things here but Subversion, JIRA, and F/C will all eventually all be linked together so I'm wondering what actually needs to specified in the config file.

Thanks,

Henry

P.S. I thought I posted this yesterday OK but I guess it didn't stick.

[Henry Widman]

I see where a DB user needs to be established but I didn't see anything regarding a schema needing to manually be defined, at least not in either of the links below:

https://confluence.atlassian.com/display/FISHEYE/Migrating+to+SQL+Server

https://confluence.atlassian.com/display/FISHEYE/Backing+Up+and+Restoring+FishEye+Data#BackingupandrestoringFishEyedata-RestoringFishEyedata

Also in this page https://go-dvcs.atlassian.com/display/aod/migrate regarding modifying the config file prior to performing a restore, it states to enter the OnDemand administrator username and password in the "auth" string, should it say admin username and password of the local instance of Fisheye instead? Would there be a need to enter the OnDemand credentials? Note that I'm wary about using the file:/// protocal in a Windows environment because it doesn't seem to work when I've tried it.

<auth username="" password=""/>	Enter the OnDemand administratorusername and password. If you use the file protocol (file:///), you can leave the username and password blank.

[Henry Widman]

Well, yet another question.

On the restore command line, what is the jdbcurl actually supposed to point to? Since I will be restoring a backup taken from the hosted instance to a local instance it looks like this is needed but am not sure what it's supposed to point to. The example in the documentation is below, but I am sure it is different for each installation. Is "crucible" below a DB name or directory name?

--jdbcurl jdbc:mysql://localhost:3306/crucible \

For an SQL Server 2008 DB that is on a different server then fisheye would it be something like:

--jbdcurl jbdb:sqlserver2008:<url to database>

[Henry Widman]

No awe inspiring answers rom the Altassian brain trust for my last set of questions? You really don't want me to spend hours and maybe days doing the trial and error thing I hope. If you can give me some direction on these I would appreciate it (really!).

The migration instructions are rather lacking when it comes to specifics and I have been checking knowledge bases and documents for info but I just can find anything that gives enough clarity (and am just getting into the app linkages and access authorizations stuff and that is something in itself).

[J. Caldwell]

Fisheye will define the scheme, you just need to create the database. See section #1 of that first link you sent.

You're jdbc bit should be like such:

jdbc:mssql://$remoteserver:$port/$database_name

where $remoteserver is the remote server, if there is name resolution, you can use a name, but IP is generally better. $Port is the port number you decided to run MSSQL on and $database_name is what ever you called your DB.

Yes..."crucible" is just the DB name.

[Nick]

Hi Henry - it is best to start a new question in answers.atlassian.com when your questions deviate from the original one. Much more likely to be picked up and answered.

It looks like J. Caldwell has helped you out now though. Are you back on track ?

Cheers,

Nick

[Henry Widman]

Nick,

My questions are all migration related so I thought I would keep them in one thread. I do have at least one other question at this point but I'll start a new thread with that.

It's rather a pain though to only be able to post a question or a follow-up comment once a day due to the Karma point thing.

J. has been very helpful and I do appreciate his answers. Not having worked on the admin side of Subversion and Fisheye/Crucible at all up until now, and although the migration pages are very helpful they are not really specific enough for someone without some background understanding, so getting some direction from the community is pretty much essential if I'm going to get the migration thing completed and working.

Henry

[Henry Widman]

I think I'm seeing a consensus here :-) OK, no question about dropping HSQLDB and going to an external DB. I may have access to a SQL Server DB on separate server, if not then mySQL will be the go to DB and it will be installed on the Fisheye/Crucbile server.

It seems that the installation process will automagically create the schema, tables, indexes, permissions, et al, that Fisheye/Crucible needs for the DB selected. Am I correct in that assumption? I'm definately not a DBA and prefer not to make like I am one :-)

[Nic Brough -Adaptavist-]

Not quite. You'll need to create the schema and a user who has access to it. The user will need rights to create tables and indices etc within that schema. But you don't need to do anything inside the schema, when you first start it, it'll create all the tables it needs.