<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body >Thank you for highlighting your points with database access implementation <br>currently used in vtiger.<br><br>We made a choice of adodb to have multi database support for our product.<br>The version that is used <br><br>I believe any wrapper on database has both positive and negatives, <br>whether it is adodb or pear db. <br><br>Going forward we have plans to pick up the best ideas from these wrappers<br>and come up with some db access framework which could let us maintain<br>vtiger working with different flavours of database.<br><br>We would be happy to get suggestions from our developer community on this.<br><br>Please do keep us updated on the both positive and negatives on various<br>database wrappers you have worked with and what best we can pick up from<br>them.<br><br>Regards,<br>Prasad<br><br>----On Wed, 26 Sep 2007 <b>Enrico Weigelt <weigelt@metux.de></b> wrote ---- <br><br><blockquote style="border-left: 1px solid rgb(160, 154, 255); padding: 6px;">
<div>
* Joey Novak <joey.novak@gmail.com> schrieb:<br><br>> I am not trying to argue... But, I really didn't find adodb all that<br>> complex. There are three or four functions that it uses, and that is it.<br><br>Did you have a deeper look into the adodb source (at least the one<br>shipped w/ vtiger) ? <br><br>There're such neat things like just retrieving a list of rows is <br>done by first counting the rows then fetching them one by one w/<br>absolute positioning, which requires some kind of cursors or at <br>least buffering of the whole result set. The calling code then<br>fetches the records via upcounting index. <br><br>The key problem is: treating the result set as an array instead<br>of an stream, and this breaks normal sql access schemes.<br><br>I regocnized that problem while trying to port to postgresql:<br>the driver (in the shipped adodb version) didn't support absolute <br>result record addressing for postgresql. Yes, I simply could <br>implement this (obviously jens fixed it, but I wasn't aware of<br>that this time), but I wanted to get rid of the unclean coding <br>and performance impact.<br><br>> With a few modifications to make it always use the associative <br>> array return values, instead of index based. <br><br>Right, that's the key point. But since the code structure of that<br>certain adodb version seemed very complex and unclean to me, I <br>chose to circumvent it and use pear::db instead.<br><br>> And a way to do different queries depending upon the dbms (there <br>> are only a few that it would be easier if they could be different, <br>> most can be the same).<br><br>Yeah, this requires some more hi-level functions, which can be <br>implemented by each driver individually. I've implemented a few<br>of them. For example, ::sql_concat(), which renders concatenation<br>from an list. <br><br>> As for performance, I didn't see very much in the adodb code that<br>> would slow things down. Although I may have missed something.<br><br>A deeper look into it's code flow should enlighten you ;-P<br><br><br>cu<br>-- <br>----------------------------------------------------------------------<br> Enrico Weigelt, metux IT service -- <a target="_blank" href="http://www.metux.de/">http://www.metux.de/</a><br><br> cellphone: +49 174 7066481 email: info@metux.de skype: nekrad666<br>----------------------------------------------------------------------<br> Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme<br>----------------------------------------------------------------------<br>_______________________________________________<br>Reach hundreds of potential candidates - <a target="_blank" href="http://jobs.vtiger.com">http://jobs.vtiger.com</a> <br>
</div>
</blockquote></body></html>