Re: Language wars...

["Chris Travers" <..hidden..>]

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