[Vtigercrm-developers] Next Release of vTiger

[Prasad]

Thank you for highlighting your points with database access implementation 
currently used in vtiger.

We made a choice of adodb to have multi database support for our product.
The version that is used 

I believe any wrapper on database has both positive and negatives, 
whether it is adodb or pear db. 

Going forward we have plans to pick up the best ideas from these wrappers
and come up with some db access framework which could let us maintain
vtiger working with different flavours of database.

We would be happy to get suggestions from our developer community on this.

Please do keep us updated on the both positive and negatives on various
database wrappers you have worked with and what best we can pick up from
them.

Regards,
Prasad

----On Wed, 26 Sep 2007  Enrico Weigelt <weigelt at metux.de> wrote ---- 

                                                                                    * Joey Novak <joey.novak at gmail.com> schrieb:

> I am not trying to argue...  But, I really didn't find adodb all that
> complex.  There are three or four functions that it uses, and that is it.

Did you have a deeper look into the adodb source (at least the one
shipped w/ vtiger) ? 

There're such neat things like just retrieving a list of rows is 
done by first counting the rows then fetching them one by one w/
absolute positioning, which requires some kind of cursors or at 
least buffering of the whole result set. The calling code then
fetches the records via upcounting index. 

The key problem is: treating the result set as an array instead
of an stream, and this breaks normal sql access schemes.

I regocnized that problem while trying to port to postgresql:
the driver (in the shipped adodb version) didn't support absolute 
result record addressing for postgresql. Yes, I simply could 
implement this (obviously jens fixed it, but I wasn't aware of
that this time), but I wanted to get rid of the unclean coding 
and performance impact.

> With a few modifications to make it always use the associative 
> array return values, instead of index based.  

Right, that's the key point. But since the code structure of that
certain adodb version seemed very complex and unclean to me, I 
chose to circumvent it and use pear::db instead.

> And a way to do different queries depending upon the dbms (there 
> are only a few that it would be easier if they could be different, 
> most can be the same).

Yeah, this requires some more hi-level functions, which can be 
implemented by each driver individually. I've implemented a few
of them. For example, ::sql_concat(), which renders concatenation
from an list. 

> As for performance, I didn't see very much in the adodb code that
> would slow things down.  Although I may have missed something.

A deeper look into it's code flow should enlighten you ;-P


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: +49 174 7066481   email: info at metux.de   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
_______________________________________________
Reach hundreds of potential candidates - http://jobs.vtiger.com 

                                                         
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20070926/24f57d0f/attachment-0003.html