Hi all; I have been thinking about various objections to calling our stored-proc-discovery-based relation<->object interface an ORM. The basic thing is that we are not really doing ORM stuff even though we are tackling the same impedance mismatch issues that ORMS have to deal with.
Also, I suspect that treating this as an ORM creates an opportunity for the abuse of stored procedures beyond what they are really supposed to do. If we take it too far, we could eventually find that we are having the database do things that it really should not be required to do. As a result, I am going to propose a name for the use of discoverable stored procs for db access as: SODA (Service Oriented Database Architecture). People know know me know I don't make buzzword compliance a goal at all, but in this case I think it is more clear because: 1) This really is an application of service oriented principles (namely the focus on discoverable remote procedure interfaces) to the database interface architecture 2) It is almost entirely unlike an ORM in that we map to functions rather than relations. As a bad pun, since Perl doesn't do any strong typing, we could call this process SODALite (a soft bluish rock sometimes sold at rock shops).... Any thoughts? Chris Travers ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
