[Question] External database?

[taker218]

I just saw this plugin and since the FilamentManager plugin seems to be abandoned, I wanted to take a look.

Since I have multiple printers and use the spools on all of them I have an external database for my spools. So is it planned to support an external database for storage?
In FilamentManager you could use a postgres database to store your data.

Otherwise I may need to stick to the FilamentManager for now.

[OllisGit]

This is not planed right now. I will put your request to my Backlog: https://github.com/OllisGit/OctoPrint-SpoolManager/projects/1

First thoughts:

• I think support for an existing database with a fixed scheme is maybe not possible
• Switching to an other database like mysql, postgresql were the plugin assign the database-scheme will work
• There will be a CSV Importer/Exporter function, maybe this is a solution

Or do you have other ideas to integrate an external database?

fyi: Currently I finished my other Plugin "PrintJobHistory" and I will "ramp up" my activities into the Spoolmanager

[taker218]

I don't think that you need to support an existing database.
The FilamentManager connected to an existing database server, but used a seperate database to store the data.

I think this could be a feature a lot of people would like to have. For me it would be a make-or-break feature to switch to this plugin.

I think yours could be a lot better then the old one, but I really dig the possibility to use the same database for all printers right now.

[stale]

This issue has been automatically marked for closing, because it has not had activity in 30 days. It will be closed if no further activity occurs in 10 days.

[JohnSh3p4rd]

I am also interested in a external database.

In my case, I use two printers with two OctoPrint setups, but they both use the same filament spools. Therefore it would be nice if the filament is being tracked in an external database, where both printers have access (maybe one hosts the database and the second is just a client?), or the database may be synced between the raspberry pis (don't know if this is a solid solution, just an idea).

[portcqb]

Would it be possible even using the included database to have multiple octoprint instances on the same PI use the same database if that would be easier than using and external database solution.

[fredrikbaberg]

Just saw this plugin today, so I haven't tried it yet, but I'd also like support for external database. I'm currently using FilamentManager, where data is stored in a Postgres database on another machine. That way I know the data is safe even if my OctoPrint install breaks (which happens sometimes since I'm doing some development on the same device).

I wouldn't mind if InfluxDB was supported since I already use that for another purpose, but since I setup Postgres only for FilamentManager I think most database solutions would be OK.

[OllisGit]

fyi:I am start implementing a solution for my PrintJobHistory-Plugin. After finishing, I can copy this feature to this plugin.

The status and how it is implemented is documented in my wiki: https://github.com/OllisGit/OctoPrint-PrintJobHistory/wiki/Roadmap-to-an-external-Database

[derekslenk]

Awesome. An external database for this plugin would be a game changer. Do you have a tip jar to fund certain features ?

[edrft99]

I second the tip jar! This is a big feature I am looking for.

[Doprintityourself]

My setup is 9 ocptoprint instances on 3 rpis. so 3 instances per pi

For now until there may be an external database,

wouldn't it be possible to just mount a directory of a nas where the .db file could be placed.

Is it just the db file where every spool information is stored, or are there more config files that are involved in a spool manger database instance?

If only the databasefile has to be accessed and it is possible, where can I change the path to the database
at the moment it is visible but I cannot edit it pluginmanger:

Thanks

[derekslenk]

@Doprintityourself it depends on the database type, but largely the low level system locks that even sqlite3 uses don't work well on CIFS/NFS/SMB.

[OllisGit]

Hi @Doprintityourself,
please take a look to the orig. documentation: https://www.sqlite.org/lockingv3.html#how_to_corrupt

Your best defense is to not use SQLite for files on a network filesystem.

@derekslenk thanks a lot for the hint!
I just started to "enable" the filelocation input field, but now I will skip this and concentrate on the external database feature.

[cwbullet]

I would support this addition so I can d/c filament manager.

[marneu]

Open for discussion https://github.com/OllisGit/OctoPrint-SpoolManager/wiki/rdbs-scheme-development

[ezeackermann]

Hi.

Sorry for taking the courage to comment on this. I think an easy way would be, that if one has more than one Octoprint system, one is a master and the rest are slaves.
The advantage is that a roll cannot be used at the same time in two printers, so there is no need to lock registration.
The fastest way is to put an option that says MASTER / SLAVE, then when one selects MASTER the .db file will be saved in that session of Octoprint. In the other printer, that the plugin is installed in the same way, but when putting SLAVE one has to put the IP or the host to connect.

In linux just for such cases, there is something called GLUSTERFS. I think it would be a good option.

[ModischFabrications]

DietPi actually changed the location of the installation during their update to v6.33, which is what finally lead me here. MichaIng/DietPi#3315

Changing the location of the database is necessary to change the installation location of octoprint. Is there a workaround to manually change the path until there is a supported way?

[dkalinai]

I also want some sort of functionality to access the .db from some other endpoint in my house. My reasoning is that i have home asisstant with lots of controls and would be nice to glance there for spool data. of course nothing can be done unless access to db is granted for the db storing spool info. Hope this happens some time.

[excessnet]

I would like this too, I could migrate from Filament Manager.

I also want to make a standalone interface on top of that DB, so I can see my spools outside of Octoprint :)

[ghost]

Call me crazy, but why does this plugin need to worry about how to create an external database at all? PostgreSQL and MySQL can be installed on any raspberry pi or computer for that matter and from there you just need the connection information for any client that wishes to use that database. There are dozens of how-tos for installing these databases and they both support having multiple clients simultaneously. The chatter around accessing the database file(s) from multiple locations is terrifying, no offense intended!

The way I see it, if you have this plugin installed currently, it works with its own database and it should be left at that. If you decide you want to use an external database, this plugin should probably just take the connection info and let you connect to that new database. If users need to migrate the data, exporting to CSV and importing from CSV might be a reasonable tool for most use cases. Just my $0.02.

[moong8te]

Hello Andrew,

your summary seems to be correct for a large number of users.

There is however another group of users who are operating at least two or even more printers.
With that use case it gets a little more complicated.

While spool manager is already supporting the external database concept there are more things to consider.

What if you have two printers and two octoprint installations.
How can you keep track of a single spool across both systems.
Where is the database stored, on one of those Raspi's? Do both Raspi's then need to be running for the second printer to work properly and have access to the master database?

To my understanding this is what this thread is about.

For instance I have two printers and each of them has a dedicated Raspi as they are not standing close to each other. If I want to use a spool that I used with printer1 on printer2 I log into octoprint of both of them and manually copy the spool values from one spool manager to the other which is quite time consuming if you switch spools a lot.

This is why it was asked to have an external database, maybe even synchronizing spool data to a central location like the cloud to solve this problem for this specific user group.

If you have only 1 printer you are basically not having this issue ;-)

[ghost]

What if you have two printers and two octoprint installations.
How can you keep track of a single spool across both systems.
Where is the database stored, on one of those Raspi's? Do both Raspi's then need to be running for the second printer to work properly and have access to the master database?

I would have to argue that the implementation of the database should be left up to the user, run it wherever you like. If you only have raspberry pis to run it on, naturally the database host must be running and accessible by any clients - it has to run somewhere. The beauty of having an external database is that it doesn't matter who/what/where it is hosted as long as they clients can reach it, you're good. Run it in Amazon RDS if you want to. This plugin will have to accommodate the idea that the database is shared across multiple instances but that's part of the engineering that goes into the whole thing, anything beyond that is just extra work for the developer(s). I feel like there might be some misunderstanding about what it means to share a database server across multiple clients - the end result is that if you read the same database table from two clients, they will both get the same data. Synchronization is implicit in an external database because all the clients are reading from the same source.

There's no point in asking @OllisGit to spend the time and energy on setting up an external database for users, again, there are hundreds of how-tos online and a little education is all that's needed, not more software from a volunteer open-source developer.

I'm more than happy to share my experience in this space if it would help the project, I'm quite interested to see where this goes.