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

Re: Call for testing experimental patch

David Tangye wrote:
On Tue, 2006-09-12 at 23:41 -0700, Chris Travers wrote:

That is what the insert's are for :-)   If they fail you have
Yes, oh OK, so migration from SL will need to involve re-inserting all
the old SL data eg create a new dataset in LedgerSMB, and then will a
backup file from SL run OK?
Wrong table.  The transaction id patch inserts all existing transaction id's into the id_tracker table.  This ensures that they are unique.  These are the inserts I was talking about.
Think of this as "scaffolding."    

        The meaning/usage of 'id' (and 'num' and 'code'?) needs to be
        and consistently used, otherwise you get confusion and bugs
        written into         the system down the track.

Agreed.  But again, do we rewrite  the app from scratch which is what
would be required, or do we stabilize and fix in place?
Both :-)

Stabilize. Add nothing new. And then redevelop. Don't get stuck with
creeping enhancements into a schema/technology that cannot handle it.
Its like quicksand. I am sure you have been there.

If you can possibly plan to do it that way, that's what I would try very
hard to do. I don't mean throw everything away. Hmm, then again, the few
times I took over others' apps, sooner or later I almost always realised
it was far more effective to just bite the bullet and start pretty-well
Well, there are two problems with this approach.

1)  you leave the existing users out in the cold
2)  the amount if immediate development work to the first release means that it is far less likley to be successful.

Our current approach is to look for the things which need fixing most and re-engineer them in place first.  Then we can take our time with the rest.  In essence this means stabilizing things, fixing the worst of it, and then re-engineering things bit by bit.

The most critical table in LedgerSMB is the acc_trans table because this holds all the financial transaction data.  Fortunately this is one of the only tables which doesn't have to assume braindead inserts.  I think the only thing left to do is add a foreign key constraint against id_tracker  but I want a little more time to test this.  Once that completed, I think I will tackle the Shipto tables, and once that is sane, we can more easily fix the rest of the schema.  We plan to have multiple shipto support next version (but this has not been committed to svn yet so no guarantees), but the version after is a good target for reworking the shipto schema so that it works a bit better.

Best Wishes,
Chris Travers