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 ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
