A porting to Postresql DB is something possible in short time?

Hello,
we got some requests to use Postgresql on Idempiere ERP implementation and for the WMS it could very helpful to use the same environment for several motivations.
Would it be a very dangerous and not recommended process using OpenBoxes ?
Are there any constraints related to the way the code was written using maybe low level features/functions drown in code typical and specific of mySQL that cannot be bypassed ?
Postresql has the spatial database extender PostGIS that in a logistic evolved environment is something that is gonna be used and very interesting. For istance automated forklift that use gps localization to find warehouse items and other sofisticated solutions that use special drones for inventory processes management.
Thanks
Giovanni

Thanks for the question. In general, it should be possible to do Using other SQL databases · Issue #29 · openboxes/openboxes · GitHub, it just might require a bit of work. I did a proof of concept a few years ago in response to a question I was asked via email. Unfortunately, I did not record the issues I encountered so I’m going to need to run through the process again. I’m off on holiday until August 16, but I will try to look into this when I get back.

Would it be a very dangerous and not recommended process using OpenBoxes ?

I would not say it’s dangerous, but it might not be an easy solution. Liquibase (our database migration tool) supports multiple database engines, so it’s theoretically possible. We might just need to find workarounds for certain database-specific features and then support a very limited set of databases and versions. For example, once we migrate to MySQL 8 / PostgreSQL 12 we drop support for older versions so as not to add a huge amount of overhead for our very tiny development team.

Are there any constraints related to the way the code was written using maybe low level features/functions drown in code typical and specific of mySQL that cannot be bypassed ?

Yes, we’re using views and probably a few MySQL specific features that we’ll need to find workarounds for.

Postresql has the spatial database extender PostGIS that in a logistic evolved environment is something that is gonna be used and very interesting. For istance automated forklift that use gps localization to find warehouse items and other sofisticated solutions that use special drones for inventory processes management.

I have been wondering how we were going to implement the internal warehouse positions, so thank you for reminding me about PostGIS. But using MySQL for the data store does not prevent us from using multiple data stores for different features. I would probably architect the GPS locations as a separate microservice. In fact, I was planning to investigate storing GeoJSON GeoJSON - Wikipedia objects in a document store to handle the internal position issue. Those objects could then be exposed by an API and referenced within the main database.

So I wouldn’t spend too much time worrying about changing the data store for this particular use case as a more decoupled approach would allow us to use the right database engine for each new feature.

Thanks so much for prompts reply and sorry for disturbing you.
I’ll wait for your coming back for sure

No worries. I’ll be responding to support emails / discussions during my vacation, I just won’t be able to do much development / investigative work. So feel free to continue the conversation.