Just speculating still, but if DBTNG has a fairly cleanly severable interface, and CiviCRM core were to use it, there would be little bloat for CiviCRM for Joomla. CiviCRM for Joomla doesn't really get used as a development framework in the way that CiviCRM for Drupal does, just because of what the CMSes are good for. I get that there is an unnecessary new layer for CiviCRM which is a drag. I'm still unclear if there might be an upside in terms of making CiviCRM integrated with Fields, Views, etc as 'native' objects rather than as external objects with 'plug-ins' written for them.<br>
<br clear="all">Joe Murray, PhD<br>President, JMA Consulting<br><a href="mailto:joe.murray@jmaconsulting.biz">joe.murray@jmaconsulting.biz</a><br>skype JosephPMurray twitter JoeMurray<br>416.466.1281<br>
<br><br><div class="gmail_quote">On Fri, May 7, 2010 at 1:32 PM, Sami Khan <span dir="ltr"><<a href="mailto:sami@etopian.net">sami@etopian.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
There are plenty of well defined PHP ORM projects out there; also<br>
another abstraction layer over PDO which is already a database<br>
abstraction layer just to do it the Drupal way doesn't make sense to me.<br>
<br>
Sami<br>
<div><div></div><div class="h5"><br>
On Fri, 2010-05-07 at 09:56 -0700, Michael Prasuhn wrote:<br>
> Well, what the database layer in Drupal 7 does and doesn't do is a little blurry sometimes. For the most part it functions as primarily a query builder and abstraction layer (now supporting 5 databases!*). It is not however, an ORM. In that sense DBTNG isn't really suited for any type of data structure over any other type. Drupal 7 is focusing some of the functionality of an ORM at the entity level, with it's Field API. At this point, the line between easily removed library and tightly coupled code is crossed, and that functionality isn't possible without moving most of the functionality into Drupal.<br>
><br>
> Could a simple ORM be built on top of DBTNG? I don't see why not, but at that point it's not really a 'Drupal like API' anymore, and you'd be back to where you started, although the ORM code would look more familiar to Drupal developers.<br>
><br>
> -Mike<br>
><br>
> *MySQL, PostgreSQL, SQLite, Oracle, and MS SQL Server<br>
> __________________<br>
> Michael Prasuhn<br>
> <a href="mailto:mike@mikeyp.net">mike@mikeyp.net</a><br>
> <a href="http://mikeyp.net" target="_blank">http://mikeyp.net</a><br>
><br>
> On May 7, 2010, at 6:12 AM, Joe Murray wrote:<br>
><br>
> > I'm trying to get my head around architectural options for CiviCRM 4.0 that might allow one to more easily leverage of 'Drupal as a developer framework' as opposed to 'Drupal as user CMS'. This would IMHO meet a CiviCRM goal of increasing its developer community.<br>
> ><br>
> > I just want to talk about the database layer right now to keep things focussed. One of the frameworks being consider as a replacement for the PEAR library (DBDataObject and HTML Quickform in particular) is the Zend Framework. It uses PDO libraries. DBTNG for Drupal 7, as I understand it, also sits on top of PDO. I find Mike Prasuhn's information about the modularity of the Drupal 7 db layer to be very interesting. For those who don't know, CiviCRM currently uses a fairly traditional tiered architecture, and generates its data layer code from an XML representation of its data schema for the most part (some business layer logic bypasses the Data Application Object (DAO) layer by reading directly from the MySQL tables for optimization purposes, for example). I imagine that the DBTNG layer is focussed on supporting Drupal data structures, but I believe it has some support for creating access to arbitrary non-Drupal data stores as well, which CiviCRM might qualify as.<br>
> ><br>
> > Is it remotely feasible to think of using DBTNG as the primary database layer for CiviCRM 4.0? What is the overhead of using for non-Drupal sites? Or is it better to imagine setting up access to the couple hundred tables in CiviCRM via DBTNG's external datasource structure, and then using that as a good way to integrate with fields, views and that good stuff?<br>
> ><br>
> > Just trying to explore whether there is some common ground here.<br>
> ><br>
> > Joe Murray, PhD<br>
> > President, JMA Consulting<br>
> > <a href="mailto:joe.murray@jmaconsulting.biz">joe.murray@jmaconsulting.biz</a><br>
> > skype JosephPMurray twitter JoeMurray<br>
> > 416.466.1281<br>
><br>
</div></div>> _______________________________________________<br>
> consulting mailing list<br>
> <a href="mailto:consulting@drupal.org">consulting@drupal.org</a><br>
> <a href="http://lists.drupal.org/mailman/listinfo/consulting" target="_blank">http://lists.drupal.org/mailman/listinfo/consulting</a><br>
<br>
<br>
</blockquote></div><br>