Hello,
We have a bunch of Jira Server Plugins, that are available in the Marketplace. Currently, we are using Jira DB to store the plugin-specific data.
Now we are working on migration to Jira Cloud, where Jira DB is not available.
Am I right that with Jira Cloud plugins we need to force users who want to install the plugin to set up a specific DB and prepare it to be ready for the plugin?
Thanks
@PavelMelnikov welcome to the Atlassian developer community. (Although, if you have a bunch of Jira Server Plugins, you must have been “lurking” for some time!)
Direct access to a database opens a lot of possibilities so the answer is “it depends”. First, there are storage options in both Connect and Forge as app platforms. For Connect, there are entity properties; for Forge, a key-value store. Those options might prevent you from needing any database.
On the other hand, there are many reasons you might need a real relational-database. If so, it would be good to hear your use cases. That said, I have not seen Cloud apps that expect customers to run their own database. Typically, that is part of what a Cloud app does. In fact, even if entity properties or Forge storage were the right solution, the default libraries in JavaScript (Atlassian Connect Express) and Java (Atlassian Connect Spring Boot) both use a database to store customer authorizations in the form of shared secrets. There is usually a database, even if it doesn’t store user-generated content.
Hello @ibuchanan ,
Of course, we keep to the idea that users should not do anything except for plugin installation, supposing that plugin will create the database structure as it does on Server apps.
Here is the case. One of our plugins stores assignee feedback. And because there can be several grades given by different assignees (as designed) the reports of ours cannot just get current assignee. That’s why we remember who It was back then including some other parameters. And this is just one of the cases. For some other plugins we store configuration settings based on project or user.
So is it possible to have an automatically deployed database structure on Cloud without the need for users to set it up? And so that we(or plugin users) do not have our own Cloud infrastructure(AWS, GCP, etc.) for plugins to connect to.
I think your last statement best captures what we believe about our Cloud customers: they don’t want to run infrastructure (even if it is Cloud infrastructure). And, we also understand your desire for the same. Specifically, we say that you will love Forge because:
- Build apps, not infrastructure: Write an app in minutes while the platform takes care of security, compute, and storage.
In contrast, Atlassian Connect is much more “you build it, you run it.” For the cases you mention, you would surely need to run a database. Just to be clear on your original question, I don’t think we have ever recommended or designed a system where customers run their own database. It might be possible but I’m sure it is not desirable.
Forge storage or entity properties (both linked in my reply above) do seem appropriate for the simple case of “configuration settings based on project or user”. I can even imagine using simple key-value store for the concept of “assignee feedback”, even if there are different grades given by different assignees. Given the right key structure, I know the data wouldn’t be constrained to just the current assignee.
Although we believe key-value stores bring many advantages, they are not a perfect replacement for RDBMS. There are patterns of reading data for which RDBMS is optimized that is not appropriate to a key-value store. You haven’t indicated anything that says you need one, but I’m trying to be clear that Forge storage is not an RDBMS. If you can live with the constraints of key-value storage, then I think Forge is a good solution.
Hi @PavelMelnikov,
I’m just going to jump in here with a comment about the Server to Cloud migration. Currently we have a migration path for Jira Server to Cloud using the Jira Cloud Migration Assistant. This also includes app migration for your data. However, you need to write your own code to bundle up your data and then use the App migration platform to send the data. We look after storage and notifications. But this pathway is only for Connect apps. As @ibuchanan pointed out, for a Connect app you run the service, the storage and everything else. And you’re responsible for the import and translation of the data from server to cloud. We also provide REST endpoints to get the mappings of server to cloud ids for all the required values.
You can review all the documentation for App migration here
Regards,
James.