[consulting] CiviCRM / Zend Framework / DBTNG

Tue May 11 16:04:53 UTC 2010

No, at this point, the CiviCRM project does not seem to have any plans
to make Drupal a requirement for CiviCRM 4.0.

If CiviCRM ever does leverage Drupal internally, it will still be CMS
agnostic, and Drupal will be used as a framework only. Drupal would be
a 'requirement' for other CMS users only in the way that the 18 MB
'packages' directory that is currently shipped with CiviCRM is a
requirement aleady. Code from Drupal would replace large portions of
this code, and it could be largely transparent to the end user, just
as the third-party packages are now.

Also, unless things have changes since the initial performance tests,
PDO/DBTNG is actually the same speed or faster as compared to the
prior database layer. My best guess is that FieldsAPI and the new UX
modules have more to do with the performance hit, but that's just a
guess.

All the Best,

Matt Chapman
Ninjitsu Web Development

--
The contents of this message should be assumed to be Confidential, and
may not be disclosed without permission of the sender.

On Tue, May 11, 2010 at 6:10 AM, Jim Taylor <jim at rootyhollow.com> wrote:
> Is the goal of 4.0 really to make Drupal a requirement?  I'm a fan of
> being CMS agnostic, I mean lets be real here Drupal is awesome (and our CMS
> of choice) but it still has many less installs than Wordpress or Joomla.
> My understanding is the main reason Drupal 7 is slower is the PDO/DBTNG so I
> would be reluctant to add more processing to the system, we already have a
> reputation for slowing things down.
> On Fri, May 7, 2010 at 2:07 PM, Matt Chapman <matt at ninjitsuweb.com> wrote:
>>
>> I'm currently reviewing the Entity API module as the possible missing
>> piece:
>>
>> http://drupal.org/project/entity
>>
>> All the Best,
>>
>> Matt Chapman
>> Ninjitsu Web Development
>>
>> --
>> The contents of this message should be assumed to be Confidential, and
>> may not be disclosed without permission of the sender.
>>
>>
>>
>> On Fri, May 7, 2010 at 10:42 AM, Joe Murray
>> <joe.murray at jmaconsulting.biz> wrote:
>> > 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.
>> >
>> > Joe Murray, PhD
>> > President, JMA Consulting
>> > joe.murray at jmaconsulting.biz
>> > skype JosephPMurray twitter JoeMurray
>> > 416.466.1281
>> >
>> >
>> > On Fri, May 7, 2010 at 1:32 PM, Sami Khan <sami at etopian.net> wrote:
>> >>
>> >> There are plenty of well defined PHP ORM projects out there; also
>> >> another abstraction layer over PDO which is already a database
>> >> abstraction layer just to do it the Drupal way doesn't make sense to
>> >> me.
>> >>
>> >> Sami
>> >>
>> >> On Fri, 2010-05-07 at 09:56 -0700, Michael Prasuhn wrote:
>> >> > 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.
>> >> >
>> >> > 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.
>> >> >
>> >> > -Mike
>> >> >
>> >> > *MySQL, PostgreSQL, SQLite, Oracle, and MS SQL Server
>> >> > __________________
>> >> > Michael Prasuhn
>> >> > mike at mikeyp.net
>> >> > http://mikeyp.net
>> >> >
>> >> > On May 7, 2010, at 6:12 AM, Joe Murray wrote:
>> >> >
>> >> > > 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.
>> >> > >
>> >> > > 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.
>> >> > >
>> >> > > 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?
>> >> > >
>> >> > > Just trying to explore whether there is some common ground here.
>> >> > >
>> >> > > Joe Murray, PhD
>> >> > > President, JMA Consulting
>> >> > > joe.murray at jmaconsulting.biz
>> >> > > skype JosephPMurray twitter JoeMurray
>> >> > > 416.466.1281
>> >> >
>> >> > _______________________________________________
>> >> > consulting mailing list
>> >> > consulting at drupal.org
>> >> > http://lists.drupal.org/mailman/listinfo/consulting
>> >>
>> >>
>> >
>> >
>> > _______________________________________________
>> > consulting mailing list
>> > consulting at drupal.org
>> > http://lists.drupal.org/mailman/listinfo/consulting
>> >
>> >
>> _______________________________________________
>> consulting mailing list
>> consulting at drupal.org
>> http://lists.drupal.org/mailman/listinfo/consulting
>
>
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>
>