Move sqlstore and mongostore to separate repos
Neal opened this issue · comments
Having sqlstore and mongostore in this repo adds unnecessary dependencies so it's worth considering moving them to separate repos that can be imported as required.
I completely agree.
This is definitely something we could do, I guess the 2 hang ups I have are
- Does this split cause an unintuitive deviation from the official Quickfix implementations in other languages, I think they bundle their various MessageStore drivers all together like it is currently, but I can take a closer look at each..
- This would impact a chunk of critical unit tests, so a migration to your proposal would involve some non-trivial changes to the unit test framework ensure those test paths are still being executed efficiently.
Very happy to discuss this a bit. Another very non-trivial change to the test framework I would like to see would be stripping out the ruby deps.. But that may be out of scope for this.
I understand and appreciate your desire to be aware of backward compatibility and desire to maintain parody with other languages architecture. I would caution against letting other languages dictate architecture in go, keep an eye out for "why" they did "a thing" and if it was an artifact from that other language that forced them into the architecture box given. I am very grateful to you for your hard work and continued effort with this project. Either way is not a wrong choice and will work for me. I personally do not use the sql database drivers in my implementations due to my need for superior speed to parse and save FIX messages. I see the inclusion of the DB store files in this project as a "maybe nice to have example SDK" that could be moved out for those that need a good starting point when implementing a datastore in their back end application.
Sure, I think the decisions in those repos do have some bearing on what we could or should do in this one, regardless of some flexibility we are afforded in the go ecosystem. I think the main point then here now regards what the testing workflow should be. Both through github actions and on-machine