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

Proposals for 1.4 framework changes



Hi all;

As I am going over it, it seems our reasons for avoiding Moose have
become less of an issue and now some of our dependencies depend on
Moose.  Consequently I think I am going to recommend we start using it
for new code starting with 1.4.  The original reasons involved lack of
support with mature versions on many distributions, and the fact that
it has a lot of dependencies.  However, we now have dependencies that
depend on Moose, so I don't see a reason not to use it.

The second set of framework changes I would propose for 1.4 involve
stored procedure argument semantics and support for these.  For 1.4, I
would recommend going to:
arg_ as a prefix meaning an external argument not intrinsic to the
type being processed, and prop_* which would refer to the property
list of the object calling it.  Thus we might see:

create or replace function get company__get(arg_id) returns company_ext as

The above would suggest we do not yet have a company we are pulling,
and therefore expect the argument to be supplied from input rather
than from an object.

CREATE OR REPLACE FUNCTION asset_report__approve(prop_id) RETURNS
asset_report as...

This would indicate we currently expect that we have an asset report
we are just trying to approve, and therefore would assume we grab the
id from that object.

I think we'd have to check for in_ on the front of the first argument
and handle the current way in order to avoid bugs in our code......

Additionally, and this becomes a bigger deal for financial
transactions, is I would like to set up arguments so we can handle
arrays of hashrefs in properties or arguments and translate these
correctly into arrays of tuples in the database interface.
Consequently:

CREATE OR REPLACE FUNCTION journal_entry__save(prop_reference text,
prop_description text, prop_post_date date, prop_lines
journal_line[])......

These are actually pretty easy to query (select sum(amount) = 0 as
balanced from unnest(prop_lines) l)

This would allow all journal lines to be passed in at once, allowing
us to check for imbalanced transactions before one is posted.

On the latter, DBD::Pg should do most of the heavy lifting for us if I
understand correctly.

Any feedback?
Best Wishes,
Chris Travers