Hi Ed; I think you misunderstand the problem. I think we all welcome the discussion, and this email is largely put together to help explain where we are coming from so that the position makes a bit more sense.
It isn't that you can't do stored procedures via most ORM's but rather that there are no extremely elegant ways to do what we want and still avoid having to rely on ORMism's for database design. I.e. we are doing the db design first, and then building lightweight objects around that design rather than going the other way around. I am not sure that 90% of the code will be in stored procedures (could be more, could be much less), but the idea is that at the center of the application is an intelligent database which is accessible by this and other applications through a specified set of interfaces. In essence doing it this way allows one to have a single unified data model which is accessible nearly identically from Python, Perl, PHP, Ruby, C, or whatever your language of choice is without adding questions of data integrity. >From an MVC perspective, think of this being an application-independant M. This also means that rather than doing object-> relational conversion, we are going the other way, which again breaks ORM approaches badly. I actually see the ORM problem as lacking any possible elegant solution because the relational and object models are simply too different. It is OK, if you start from object definitions, and are using the db largely for storage, as most MVC frameworks assume, but that is not what we are doing. I can understand the idea that there is some attractiveness to the idea of using a framework that other developers will recognize and be able to work with quickly who are used to such a framework. However, in this case, I think it actually works against us. I tend to think that if one is building a Catalyst or a Rails application, it should be done as much as possible along the best practices of those frameworks (including using the ORM) and if one is going to diverge from these, one should be more cautious about using the frameworks so that structure and design are clear. Since our code will be basically structured in an MVC manner even without a framework, but since it will not follow the conventions at all in the Model components, I think that the cost of using Catalyst or other conventional frameworks makes the proposal a net negative. JMHO, of course, but so far everyone on the core team seems to agree. Chris Travers ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
