I'd like to try running JIRA with a database that is not among those supported by Atlassian - how can I configure JIRA to use the JDBC driver from that RDMS instead of the ones that come pre-installed?
Hi Karl,
It would depend on the database you're using. You would need to refer to the documentation for that db to determine how to configure the jdbc path and then you can use the JIRA application configuration tool to make the changes to your instance.
Cheers,
Branden
The database in question is Mimer SQL (http://mimer.com/) and it comes with a JDBC driver.
I have used the configuration tool before, but is that not something I typically use to tweak an existing installation? What I am trying to say is that I want to install JIRA with Mimer SQL as database backend but from from what I recall from the installation procedure one has to pick one of the kosher ones, right?
That means that I would install it with HSQL, for instance, but to then go from HSQL to an empty Mimer SQL (or any other database for that) can not be trivial.
You don't have to use the Jira config tool to setup Jira, but it tends to be easier if you do.
In theory you could edit the dbconfig.xml file in the $JIRAHOME directory in order to setup Jira to use this database. The problem here is that we don't have any idea of exactly what the parameters should be for a database of this type.
If you look at all the supported database examples listed on: Connecting Jira application to a database you will notice that each of these has a sample dbconfig.xml that is specific to that database type. If you are really determined to use this database, I would study these to see if you can work backwards to figure out all the parameters needed to connect to this database.
However I don't think this is going to work. Jira is coded with specific methods and instructions for each of the supported database types: oracle, MS SQL, postgres, and MySQL. Each of these have differences in regards to data types, sequences, transactions, table creation, field types, field lengths, foreign key constraints, and so on.
There are some users out there using unsupported databases like MariaDB or Percona. These are unsupported too, but they tend to have an edge over this Mimer SQL because they are derivatives of MySQL. Even these can still have problems what would leave these instances broken, but there are users still able to make Jira work with this database type. In the case of Mimer, I don't even know how to begin to make this work. It feels like this is not a derivative of any of the existing supported database versions, so this might be entirely new ground for Jira to try to use this kind of database.
Using an unsupported database would lead to confusion I would say. Issues you would face and have no idea why it happens.
My reason for this is that my company is Mimer, i.e., we build and sell a SQL database server software. In keeping up with the old "eat your own dog food" adage it is rather important for us to use our own software.
But I see your point, of course, and I am fully aware of the ramifications. Still, I would like to try to get Jira to work with our own software so as to be able to properly evaluate if it will be worth the extra work to use ours instead of the officially supported ones.
My thinking is that it either works or it doesn't. There is usually no in-between. And if I have my backups in order I could always fall back on one of the other, were we to run into problems later.
No, Mimer SQL is not a derivative - it has been around for 30+ years.
From what I gathered is Jira heading the Hibernate way and that means, at least to me, that the time of database specific queries and solutions should be gone. On the other hand have I also gathered that Jira is not fully there, hence there might be some hiccups.
So, Andrew, given that you are Atlassian I take careful note of your words. As I stated in another reply, this is just a matter of pride. I will not spend an insane amount of time trying to get this to work. Still, is is worth a try, you'll agree.
ok - so the whole intent is different here. You'd want to explore possibilities rather than run your enterprise on it for the moment.
Well… :-)
Both, actually. If it works, all the better!
It looks like you're new here. Sign in or register to get started.