|
Hi, Overall I'm completely in favor with just about everything in this thread. To summarize, as I see it: - Create a 2.0 branch, which at first may be used for experimentation around how to best clean up the schema/support new features/etc, and gradually solidify that into the next major version. - Don't guarantee backwards compatibility in this branch, but don't break things for no good reason. - Eventual upgrade path will be a data migration (and to take a step further, perhaps we only specify full support for migrating Accounts, ECAs, parts/services, GL/AR/AP/payments -- the core accounting/bookkeeping stuff, while possibly suggesting a clean break for the other items if they prove difficult to migrate?) - 2.0 should focus on the optimal accounting design, providing an API and a plugin framework to keep extensions separated enough to be easily maintained outside core - 2.0 should be spec-driven -- we should build out in tandem with documented user stories, living schema, API documents, and tests. Those may be unstable until we're all satisfied they are sufficient, but we should avoid a "code first" development pattern for anything beyond experimentation.
I think this last point should be the main thing that coordinates our efforts across the 1.x and 2.x branches -- we should be able to take our BDD tests for 1.x, evaluate whether there are steps to eliminate or improve, and use those as a starting point for 2.x (never mind that they will all fail at first). Then flesh out the tests for the core accounting functionality that we may not have gotten test coverage for yet, particularly those areas that are giving us trouble in 1.x and need to solve for 2.x. And then go from there...
Regarding the 1.x feature freeze and support for managing
customizations, I really don't have anything to add -- it's not an
issue for us, and we aren't working with any clients on LSMB (let
alone any with customizations to maintain).
The only thing in the thread I'm not sure I'm entirely seeing the
need for:
On 12/13/2016 12:46 PM, Erik Huelsmann
wrote:
I come from the fast-and-loose PHP world where pretty much nobody uses referential integrity. Mainly because it wasn't even supported in MySQL until well into the lifetime of the major projects. One thing comes to mind that might be a problem for having the database enforce referential integrity, and it goes straight to the heart of supporting pluggable extensions (and shows my lack of experience with this level of database administration) -- can you have referential integrity for a column referring to columns in one of several different tables? The scenario I'm picturing is CRM. I can see having a really basic contact management plugin that is closer to SQL Ledger than what we have in LSMB 1.4 -- essentially just ECAs, no entities. And other plugins that might supply contacts, companies, or whatever. I'm picturing that instead of a single column on one of the core finance tables that links to an ECA ID, instead, we have two columns -- one for the ID, and the other for the table this ID belongs to. This would allow a plugin to define their own table, and use it as an alternative to our built in ECA. But unless I'm mistaken, this won't work if we enforce referential integrity on the eca_id column. ... and a step further, why do we need referential integrity? Isn't the point being able to cascade delete all data related to a particular row in one table -- and prevent deletions of rows that are referenced in other tables? I think of the accounting system as an append-only log, there should never be any actual deletion, just correcting transactions added to the journal. So I'm failing to see why this is useful to us at all. Otherwise, I think we're all in violent agreement here... Cheers, John Locke http://www.freelock.com |
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________ Ledger-smb-devel mailing list ..hidden.. https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel