I'm not sure if this is a plea, a question or a suggestion.
Does the community think there's mileage in choosing and using a single database for all things Octoprint? For example, I use OctoFarm and PrintJobHistory and I have installed FilamentManager because PrintJobHistory has a stack of Plug-in dependencies. I already have a MySQL instance running on a separate P, with an internal hard drive.
FilamentManager wants postgresql and doesn't seem to want to play ball with MySQL. And OctoFarm runs MongoDB, so its all downhill so far. Because every one is different
What's the possibility, practicality or feasibility of at least being able to configure the plug-ins to be able to use a single database - I don't want databases on a microSD card, nor spread over three or four instances of Octoprint.. I need PrintJobHistory, which means I need FilamentManager, but I only want ONE database with Filament spools in.. Maybe its a feature request for OctoFarm, of which I'm a Patreon -perhaps I can do it all with OctoFarm???
Hi @rcw88,
providing a general programming interface in Octoprint could be an idea, but each database has special functionalities. These results in a huge amount of effort to encapsulate in a simple to use api.
That was one of the reason why I choose an out-of-the-box database interface called PeeWee for my Plugins. But this O/R Tool also only support a handful of databases (sqlite, mysql, postgresql). No TimeSeries database (e.g. needed for temperature curves), NoSQL- or Cloud-Databases.
Currently my PrintJobHistory-Plugin use a local database, but in one of the next releases there will be an option to connect to an external database.
Also, I will release, in a couple of days, a RC of my new SpoolManager-Plugin which can use the same database infrastructure.
...as a conclusion...currently you need to get in contact to each plugin author and raise a feature request.
Please remember that plugin authors are (for the most part) unpaid volunteers and their plugins are usually personal projects that they graciously decided to share. If they use a database, then most often it's one they are familiar with.
When you contact one of these plugin authors to ask for a different database, consider offering your expertise in your database of choice. With your help, the probability of success will increase.
Thank you for taking the trouble to respond - it was an idea that floated through my grey cells a little bit of alignment in approach might make the decision making easier for all Plugin developers - its the sort of thing I do in my day job..
For Time Series data I'd never go anywhere else than RRD - because time series data, well, grows over time but that's not a good thing. I use RPiMonitor on a lot of my Raspberry Pi and Debian builds - and I use that to handle RRD temperature logging - awesome,
Thank you taking the time to respond :-), I fully appreciate the time and effort developers put into their work creating Plugins that I just don't have the time to develop. I was hoping to catch the eye of the Octoprint team as well to sow the seeds of an idea in future planning of the Octoprint 'roadmap'..
I see OctoPi very much as an 'appliance', i.e. something you build and use and add plugins to - for the the microSD card build approach is perfect - there's nothing on the card that's terribly important. But databases maybe need an SSD hanging off a Pi, from which the Pi boots, then a Pi Based database 'appliance' becomes really useful.
I have no preference as to which DB engine is used, SQL is SQL, and its only the connection strings and listening ports which vary. MySQL is 3306, generally, but it doesn't really matter. If I was using a laptop with Octoprint on it might be a different conversation, but my 3D printers generally have a habit of multiplying.
