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

Re: 1.2.x support?

On Tue, Mar 20, 2012 at 6:19 PM, Chris Travers <..hidden..> wrote:

>> Diffing / merging the entire /bin and /Ledgersmb dirs one version takes
>> some time and it is a real let down to get done with it to find
>> functionality gone.
>> Is this all wrong now 1.3 has all the features of 1.2?
> One of the significant

Oops, forgot to finish my thought.

There are a few areas of significant changes in 1.3:

These include contact management, payment/overpayment handling,
separation of duties, and security enforcement.  These affect
customizations in these areas.

A few thoughts on moving stuff into stored procedures below.

The old SQL-Ledger way of doing things was to assemble a query as a
text string, and then run it.  It turns out a significant amount of
code in SQL-Ledger actually is devoted to this query assembling
process.  If you look at most of our stored procedures, they are
basically named queries, where we handle all possible inputs in the
query rather than changing the query based on the inputs.  The
exceptions break down into a few categories but they are relatively
rare.  The queries themselves become API's and accessible to other
programmers in other languages.  I don't really see a major argument
to be made against that.  Maybe I am missing something.

I may be misunderstanding your objections but I think the big problem
here is that this argument has been dominated by two opposing points
of view:  The first says "put EVERYTHING in the database" and the
other says "put NOTHING in the database.  Only send SQL queries."  I
don't really subscribe to either viewpoint.  It seems to me the
database is the natural place to put API's involving set operations
coupled with storing/retrieving/modifying stored information,
particularly if we want to expose those as API's for other

Best Wishes,
Chris Travers

This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
Ledger-smb-users mailing list