The limited resources of two people is more than the limited resources
of one person...just a thought.
I think at some point, migrations are going to get more painful.
However if the divergence happens slowly enough it won't be too bad.
> I think that the best way forward is to be sufficiently confident to
> diverge. There is little point in just being SL with its data schema and
> a few patches and add-ons on the side. To get a more robust and flexible
> application you need a better more robust data schema anyway.
>
I agree. Diverging isn't a bad thing. Robustness is important. It is
important in my mind to keep our options open though. I'm not ready to
transfer my 3 years of accounting data to LedgerSMB but once I do, I
would not expect to be able to go backwards.
Right now, the data can go either way. Our db patches won't yet break SQL-Ledger (but stay tuned...)
The data would somehow
have to be verified to ensure it was compatible. I don't know if that
means that certain id's would need to be modified to work with the
unique id patch etc.
If the unique id patch fails to install, you have big problems.
Same with the not null patch in the last upgrade. These don't
break SQL-Ledger so much as flag serious data integrity problems that
sometimes happen. Let me explain these in detail so that you
understand.
BTW, one can also test the upgrade files by putting them in a
begin/rollback block. THis isn't a bad idea since these largely
just error when *serious* accounting data problems are found.
In some cases, if one forgets to flag accounts for the parts income
accounts, it is possible to think you are creating a part, when in fact
that part ends up with a NULL chart id. When this happens, you
sell the part that you just created, and the income part of the
transaction goes into the acc_trans but the chart_id is NULL. In
other words, SQL-Ledger says the money went into an *UNKNOWN*
account. Needless to say, this is very, very bad and if you are
running SQL-Ledger with such data, your books probably won't
balance. This is not merely theoretical either as one other
poster has had this problem and I have had to support others with
it. I am working on a fixme script that will allow one to flag
such transactions for correction.
The second issue is far more rare but even more serious. In some
cases, the id sequence can get out of whack and when this happens, it
is possible that one table may insert a transaction with the same id as
another. When this happens, the acc_trans.trans_id points to an
ambiguous reference, and both transactions will get the combined
portions of both transactions, which has the net effect of doubling
both (the reports pick up the acc_trans entries twice).
In fact if you are still running SQL-Ledger, I HIGHLY recommend adding
a NOT NULL constraint to acc_trans.chart_id and running the unique
transaction patch (though I will want to send you one with Tony
Fraser's corrections).
If by some chance the entire database cannot be ported forward, at the
very least some tables such as customers and parts need to be portable.
> The best scheme will probably not be apparent until the scope of the
> application is defined, and architecture/design defined based on that,
> ie a bit more top-down development, rather than bottom-up.
>
Perhaps a good idea would be to have an irc meeting where several people
can discuss some of these ideas. It's pretty easy to start a channel on
freenode.net for this purpose.
Already done. #ledgersmb
It only makes sense though if the
developers are willing to use the resource. The fork/spoon/spork has
been made. What we as a community need is a clear vision of what the
plans are for the future. Both immediate plans and long term plans. If
no roadmap exists, the project may not be as successful as we all hope
it will be. (openpbx is a good example of this where several develops
left the Asterisk project to create their own project which hasn't
really done much)
Well, I am thankful for all the help. If I wasn't willing to do
it all myself I wouldn't have joined the fork. I think that there
are others on the fork who feel the same way which is good. We
are moving forward though hopefully at a saner pace soon :-)
Thanks,
Chris Travers