potential for distillery and brewery use with some modifications

[bsmokeman]

I think I can breathe new life into this project.
I've scoured the web, and find this project to be the most promising to customize for use in a distillery/brewery we are launching soon. All commercial products are extremely expensive to a craft business startup. I've done enough poking around in the gui to see the commonality between brews, and distillery mashes. I see the potential to use 'Brew' to create brewdays, that match runs depending on if it is a distilled product, or a brewed product, and tracking the resultant volume of product created. I see the potential to export this from sqlite, to something like dolibarr, keeping track of bottling, and taxes paid.
I'm a developer. I'm a bit rusty, but I took a stab at pulling in the brewtarget-develop branch as a project in Qt6, then down to Qt5.15.2 when I saw the build errors. I'm down to the xercesC error, and I noticed the windows build thread in this discussion forum. I'll read through that, and see if I can get the source to build. I chose Qt because of the Qt gui, but I saw other tools in that discussion, so I'll switch to what is recommended. If the gui is edited with Qt, then Qt might be the best environment to build upon. I love the cross-compatibility, however I see a lot of potential in looking at the project from a multi-device perspective. If the database were indeed switched to a gui-chosen database engine, then connections to servers could be a possibility. that would turn the gui into a front-end for whatever platform it is installed on. dolibarr is of course a php project, installable via wamp, or on linux servers. The more professional approach is to have a cloud linux server, and if I'm looking to integrate the 2 projects, I would be looking at installing a master brewtarget installation on the same linux server as dolibarr, and writing some synchronization tools locally, or the tools would have to do remote sync. I saw documentation on how daunting the switch to sqlite was, and how it improved performance, but that may not be an issue with modern system performance. I did some research on switching database engines, and I'm seeing the modern approach is abstracted object oriented database objects. My experience with databases is rooted in direct mysql connections, so I'll have a learning curve in whatever direction I decide to take this venture.

I've forked brewtarget in my github, and I'll publish my changes to the code, and any synchronization tools I write.
My immediate goals are minor changes, geared towards organization of the database, and gui for distillery and brewery operations.

1. brewday turned into a customizable/trackable id, not just a date under recipe.
   • recipe terminology might need replaced, and I see the folder organization could be used to categorize brewery runs, distillery runs, and cider mashes
   • perhaps derived product as the parent, and batch run as the 'brewday', also style would then become recipe, to me style is more of a category, so deprecate that word. style database table would become a recipe table.
   • batch run(brewday) would be a configurable format, so that it could match on export/sync with an ERP like dolibarr.
   • distilleries get a federal designation, which might be a good prefix, then the product id could be appended to the id
     +ARDSP101- B30-7-21-2021, distillery designation, recipe(B for brewed, D for distilled, C for a cider, M for a mead) then recipe number, then date run or started...for trackability. the database for each recipe(previously style) is huge, so it is up to the distillery/brewery to choose/pick which recipes become their main product derivations.....
     -with multiple recipe databases available from the below Converter tool crash #3 importable third party recipes, there would need to be a 'chosen recipes' gui where localization changes could be made, then the derived products could result from this chosen tier.
2. database engine would be a huge undertaking, so instead the first step would be improving the code base for a single master installation, then using some third party tools to take that database, and use it for production.
   -first step export and match database tables, and batch id's for tracking in a dolibarr export
   -second step, replace database engine, so that the database connection is selectable in the gui.
   -networked database connection creates a multi-gui cross platform, networkable platform.
   -changes in one gui with the right credentials propagate to all connected clients.
3. importable third party database...

• with a central database engine, a tiered approach to beer databases could be accomplished. each importable database could have a folder in the gui, and in the setup configuration, the databases could be selectable. Since this program supports beer xml, surely a central repository of importable recipes could be accomplished.
• select from brewunited, beerrecipes.org, winning homebrew, brewersfriend, etc...
• start, or join a central united format repository for exchanging recipes
  4)automation -
  -eventually this platform could integrate with the electric brewing platform, using raspberry pi
• controlling brewdays, and boiler automation
• between equipment definitions, and brewday automation, surely we can integrate with existing respberry pi electric automation tools.

Thanks for reading this, and I hope to bring this project further than initially envisioned.
Barry Smoke

[bsmokeman]

on point number 3. importable databases, obviously there would be a disconnect between the beer xml, and all data points for synchronization. some kind of import process would be required to import recipes, and make them available for conversion into useable recipes.

[bsmokeman]

I would assume a folder based approach, depending on desired database to import

[matty0ung]

BeerXML might still be usable here notwithstanding the disconnect. It's very extensible (which is good) albeit that there is no framework/structure for ensuring that one projects extensions do not clash with another's (less good). Some of the design decisions made umpteen years ago when it was created were ... how can I put this ... wrong. But, there are ways to work around most of the problems. And, until BeerJSON is at 1.0, it seems the only open & standard format available.

[bsmokeman]

greatly depends on primary naming I would assume....which can be handled with a simple import/increment autohandler. anything with a conflict would get a (1), or (2) prefix...although beer naming seems to be a bit more standard, with less conflicts than that. will be interesting to see what we come across with a central database across multiple platforms.

[matty0ung]

In the long run, something along this lines is my aim for https://github.com/Brewken/brewken, which is a downstream project from Brewtarget (because I assume that homebrewers would not want all the additional functionality needed by a microbrewery such as the one I run in south-west France).

I wouldn't underestimate the amount of work involved. But definitely open to collaboration!

Brewken isn't yet ready to use. I'm working on simplifying the data access layer as a prelude to extending the data model. But you can probably already see a bit where I'm headed with the code.

[bsmokeman]

exactly why I posed the topic, to see where others were at....there are multiple levels of work here, syncing existing data structure, with goals of export, then completely replacing the data layer.....I'll check your project out, thanks!