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:
3. The way things are split up gives us no real hard enforcement
of referential integrity. We have partial enforcement but not what
I think we need.
Can you be more specific on this one? It's definitely one of the
things I'd like to the document collecting notes about the existing
database schema.
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
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel