I appreciate the work here, however I do see some uncertainties.

• Client should not need to know what database is used.
  • For example when importing/exporting
• Will this force the project to contain twice the amount of logic for queries?
  • I see that some queries have a switch case, but I get the feeling that more changes might be needed.
  • Best case is if gorm can handle all of this for us. Or at least 90%, with some edge-cases.
• Would prefer to have the args removed and instead be placed inside the settings file. Could also be picked up from environment variables.

Hey, thanks for the feedback,

• i looked into the client and it looks like a Header can be set to specify the file name, with that it can reduce it to a single function and remove the db info from the client.
• The code needs only switch cases for some query, as most of the statements are identical, I think the only change was the time conversion.
  And that with postgres the group by needs to be included in the select, which i think sqlite doesn't care for
• Sure I can have a look at it and remove the args, I would suggest to leave the environment since in docker it's easiest to just parse envs instead of configs.

Hey there first of all sorry for the force-pushes, somehow my git config was broken and used a wrong Github Account 😓
As I can see i removed the DB Configuration from the Client and added the automated filename via the Content-Disposition Header. The Args should now also be removed, but I am not sure on that one, would be great if you can look into it. (Just removed the flags in the settings file)

I am also open to maintain the Postgres Support.
If your fine with having an additional Query, I can also add support for mysql and/or mariadb 😄

Hi again.

To preface... I am appreciative of the time and effort you have put into this PR, given the size and the new feature.

This project has received more attention that I was expecting, leading to issues being reported, discussions created, contributions (such as this) and features being requested. As a result, I have had less time to delve into the active development myself with all that comes around it.

As for this PR. Something that should have been done as a precursor, is to firstly discuss the change before anything is done as I need to orchestrate my work with any contribution. Planning, testing, time and effort is something I would rather keep to a minimum. This is an error on my part as the README never mentions this; and for that I apologize.

Related to these changes, I have been working on a rewrite of the codebase (server side) to have it be more dynamic and maintainable so that tests can be added and further functionality is easily written.

With this said, I think we should park this PR for now. Once the rewrite is finished, or at least a good amount of progress has been made; then we can start looking to integrate your changes. My hope is to have the database layer be an interface of sorts, that can easily be swapped out. This will make it so much easier to have support for different database types.

Once again, I should have been clear with this upfront, I apologize and hope that you have an understanding.

Hey no Worries there,

and I understand you completely.
First of all I agree that it would be best noted down, that new Features should be first Discussed 👍

But the main Part from your Message concerning my Effort.
I am at this point, neither disappointed nor angry. In normal Cases I also would have created an Issue beforehand, but in this instance it was a purely selfish desire for having an external Db support, which is beneficial for running it on my Docker node. I just decided if I already put the work into it I can share my work, and either it will be approved or denied.
It was also fun and a good learning experience to work with the connection of DB and Golang 😀

If you're in the Progress of rewriting your backend, it can make sense to wait for it to be finished. With that said I am fine with closing this PR. 👍

As I mentioned before, I’d be happy to maintain the Postgres “module” if you’re not planning to.
To make it clearer that Postgres support isn’t currently planned (or is on hold), it might be a good idea to create an issue or discussion for that.

@TheGameProfi I do thank you for being understanding.

We can keep this PR open as a draft, as it will be a good reference for future work on this.

I’d be happy to maintain the Postgres “module”

I did have a quick search in the gorm docs, and they do natively support multiple databases, so hopefully the project won't require any specific maintenance in certain areas; which was also my hope as it can easily cause problems and diverge.

Sound good.
Most of the time it's the kind of special queries that are the problem like the time extraction out of a string or other functions that are not cross compatible.