Re: Call for testing experimental patch

["Chris Travers" <..hidden..>]

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
> > problems.... 
> >     
> 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
> >         defined
> >         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
> again.
>   
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