Dynmap: Can you add postgresql support

[RadioactiveHydra]

Can you add postgresql for Dynmap? I dont want to switch to mysql or sqlite

[rautamiekka]

The driver should be shipped with the Server Software, not Dynmap, and it's certain nobody's making that.

[wioxjk]

@rautamiekka
OP means, that dynmap should be able to use Postgresql also. Currently dynmap can only use mysql/mariadb and sqlite as databases.

[rautamiekka]

@wioxjk And I mean there's no point in Dynmap writing a driver (you can't use MySQL driver for Pg) for a DbS just for Dynmap which should be done on Spigot level, and it's very likely no one's gonna write that driver for Dynmap or Spigot.

[cjm721]

@rautamiekka Dynmap would not be writing a driver even if they manually added support... That is what jdbc is for.

[rautamiekka]

^ Exactly my point. If that's done yet ...

[randombk]

@rautamiekka

Postgres has a very mature JDBC driver already, at https://jdbc.postgresql.org/ (also on maven). The API is almost identical to the MySQL JDBC driver - it's just search/replace "mysql" with "postgres", for the most part.

[smmmadden]

I can tell you both that PostgreSQL is nothing like MySQL or SQLite databases. Being a DBA for over 20 years, the architecture of each database type is distinct in their own ways. I don't believe it's worth the effort to add support for Oracle, SQL Server or PostgreSQL databases due to the costs associated with licenses and most server owners couldn't afford the license/support costs that comes with the bigger DB companies.

[cjm721]

They all are relational databases. The internal implementation may be very different but from how it would be used for this project they would have little differences. Just some minor syntax changes.

[rautamiekka]

@smmmadden It's funny you're not taking into account the free variants of those systems despite talking about free systems here. It's almost as if you're only considering buying a license for a db, be it MySQL or SQLite, and it'd be the only option, an option which would be cheaper than PostgreSQL or the others.

[smmmadden]

that is not exactly what I'm saying. The developer can confirm the same as for what his customers are using and what he is willing to do for the plugin. I understand all about the free versus paid subscriptions for the database. It comes down to amount of effort to put into the plugin versus cost and actual use of it. @mikeprimm is retired and has only recently come back to update the plugin so it works with 1.12 which is great since we really need the update and appreciate his supporting it. :-)

When evaluating enhancements & issues there are five data points to consider:
Time - how much time adding the feature will take to implement
Effort - how much effort is involved to adding the feature (similar to TIme
Cost - what does it cost to implement the feature to the developer and/or plugin owners. Is this something the developer has to invest in financially to support it.
ROI - what is the Return On Investment? What does the developer get in return by adding the feature? Will it be more users taking advantage of it, or is there a financial gain or loss (due to support) in providing the feature?
Support - once the feature is implemented, what effort is involved with supporting issues being reported on the new feature when not using it as designed. This than translates back to the first 4 points.
Oh, there is one further data point - many plugin owners are either retired, work full time doing something else and have limited time/resources to make updates and some are either still in High School or College which impacts their ability to turn around any enhancement/fix. :-) Very few do this full time or have many plugins they have to maintain.

[mikeprimm]

I should be able to look in to doing this one: I'm decidedly 'out of retirement' these days - but working on a rather huge and ambitious update for Dynmap 3.0 (that should allow it to automatically work with the vast majority of custom plugin blocks without special mod-specific work - and with little such work for the remaining custom blocks). The postgres support will probably come after this work is at beta - I'm really trying to focus on the new feature, which I think has a very broad audience.

[baconwaifu]

If this is still wanted, I currently have a mostly working implementation based off the MySQL backend. Only changes needed from MySQL were some SQL types and console prints, otherwise the new code is copied verbatim from MySQL.

Only things left before I put in a pull request are the standalone server files, and a proper solution to getting org.postgres into the classpath. (My test build currently uses manual load via --classpath, which isn't sustainable for release)

A possible solution to the latter issue could possibly be an external "companion" plugin that contains the driver, and a console prompt to install that if the driver isn't found.