[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: My post-1.4 priorities






On Wed, Jan 22, 2014 at 7:28 AM, John Locke <..hidden..> wrote:
Hi,

I'm all for ripping out the financial code and replacing it. And I share Erik's concerns about stability.

Would it be possible to start by defining an API that wraps the current code, write some tests against that API, and then be able to use that to verify that the new code works correctly?

I wish.  If the old code was testable I wouldn't be in as much a hurry to replace it. 

I'm thinking either a database API of stored functions, or a web services API. If we could get that in place with some decent tests, we can then totally change the underlying schema and know when we have it successfully built. TDD. And we know we want both -- much of the app in the database, as well as a REST API.

Yeah, we should have test cases written with the new API.  Unfortunately the old code depends on sloppy scoping which makes testing more or less impossible.  I added tests at one point to GL.pm and it took me over 8 hours just to get scoping issues resolved.

Aside from the effort, the concern I have is that when we start mucking around with tightening up scoping, we may break things.

We are better off doing what I did for 1.4 and the COGS logic which is defining test cases I wanted the old code to pass (whether or not it did) and then writing those for the new code. 

Just a thought...

Cheers,
John Locke
http://www.freelock.com


On 01/22/2014 12:55 AM, Chris Travers wrote:



On Wed, Jan 22, 2014 at 12:34 AM, Erik Huelsmann <..hidden..> wrote:

On Wed, Jan 22, 2014 at 9:14 AM, Chris Travers <..hidden..> wrote:
Two more thoughts:

Ok. This is a big one. Even though I think it's a great goal to set, if it were up to me, I'd like to split this up in smaller tasks, if possible.\

At this point I don't think it is possible.  The db has to be redesigned from underneath and making that backwards-compatible is going to take almost as much time as the full rewrite.
 
One thing that I think is important for the project as a whole is that we can maintain a reasonable level of stability during the entire rewrite -- it helps with the acceptance of the final 1.5 end result.

Sure, but I would highly suggest that we not make the financial logic a moving target and try hard to avoid any new reports against financial tables in the mean time.  Otherwise, if it is a moving target, it will never get done.


Well, my point is merely that we should strive to keep trunk in working order. Maybe we should/can start this work on a branch so that even if this work turns out to be infeasible (or rather: the resources to finish it turn out to be unavailable), we'll still have a working trunk version.

Does that sound like an approach? 

Sure.  Just noting the moving target problem may mean delaying feature requests until it gets done, or doing those in the feature branch as well.

Here's my estimate as far as the minimum which will need to be redone at once:

1. We need a new db design of the following underlying tables: ar, ap, gl, acc_trans, invoice payment, payment_map, overpayment.  Providing read-compatibility may be possible, but write compatibility is not really feasible.

This means that the following have to be rewritten:

Financial transactions and sales/purchase invoices
Reconciliation
Payments
The reporting queries will need to be gone through and ported to the new codebase.

The first three replace about 12000 lines of Perl code, most of it old SQL-Ledger code as well as about 1600 lines of 1.3 SQL code.

The second involves review of another 1600 lines of SQL or so.



--
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel




--
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor lock-in.
!DSPAM:52df877f173469724526679!

------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
!DSPAM:52df877f173469724526679!


_______________________________________________ Ledger-smb-devel mailing list ..hidden.. https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
!DSPAM:52df877f173469724526679!


------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel




--
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor lock-in.
http://www.efficito.com/learn_more.shtml