Build interfaces around our postgres access

[sync-by-unito[bot]]

We should make sure that users could bring their own SQL databases into Armada. Currently we only allow postgres as our db but we should create an interface and potentially allow other databases.

This could help with test improvement as we can add mocks for SQL calls and allow us to run unit tests without an active database.

┆Issue is synchronized with this Jira Task by Unito

[sync-by-unito[bot]]

➤ Suryaansh Rai commented:

Which databases other than postgres are we expecting Armada to deal with?

[sync-by-unito[bot]]

➤ Kevin Hannon commented:

At the moment our main user will be using Postgres.

Generally our goal with this is to allow other relation databases so some that come to mind are MSSQL (Microsoft SQL Server), SQLLite, MySQL and Postgres.

I don't think we should directly support these in Armada until there is a request to support them. But what I would like to do is to start changing the code so that we could plug and match other databases.

[sync-by-unito[bot]]

➤ Abhishek Kumar commented:

I am interested too in this sir

[sync-by-unito[bot]]

➤ Kevin Hannon commented:

https://developers.google.com/open-source/gsoc/timeline

I suggest getting familiar with our project.

I've created some other issues for people to play around with. We are excited to have this much interest but I ask that you don't take this project unless you are officially allowed to do so via GSOC application.

[sync-by-unito[bot]]

➤ Geoffrey Wilson commented:

I would say abstracting as necessary so that SQLite or Postgres can work interchangeably is a good concrete starting point, as we could then use SQLite for running unit tests instead of requiring Postgres. The existing tests with SQLite db provider would provide an indicator of success.

[sync-by-unito[bot]]

➤ Albin Severinson commented:

We're using postgres-specific SQL calls for performance (specifically, the postygres-specific copy wire protocol). In my opinion, adding interfaces around SQL calls would be counter-productive for this reason. I.e., I don't think we should do it.

[sync-by-unito[bot]]

➤ Dave Gantenbein commented:

severinson what's your suggestion for how to solve the underlying issue (we need PG to run unit tests)? I'm pretty sure you expressed an interest in having them run quickly. 😀

[sync-by-unito[bot]]

➤ Geoffrey Wilson commented:

I think there are two benefits -- less external dependency for unit tests and more openness in the system which might aid adoption. As long as we keep the postgresy performance stuff in that provider, I don't think it's counter-productive.

[sync-by-unito[bot]]

➤ Dave Gantenbein commented:

No, this project is still valid, please proceed!

On Fri, Feb 24, 2023 at 12:57 PM Maureen Ononiwu @.***> wrote:

Does this mean this is no longer a gsoc project?

— Reply to this email directly, view it on GitHub https://github.com/armadaproject/armada/issues/2121#issuecomment-1444145204, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEO3Y3W6UW77XUQXF6KIL3WZDZAZANCNFSM6AAAAAAU4DDELQ . You are receiving this because you commented.Message ID: @.***>

[sync-by-unito[bot]]

➤ Abhishek Kumar commented:

Is this project valid then can I proceed to learn more about it?

[sync-by-unito[bot]]

➤ Neeraj Gartia commented:

Hello kannon92 suprjinx , I work to work on this project. Where can I discuss about the same?