Bugs item #2915566, was opened at 2009-12-16 14:59 Message generated for change (Comment added) made by stmane You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2915566&group_id=56967
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andreas Streichardt (m0p) Assigned to: Nobody/Anonymous (nobody) Summary: Several PHP client issues Initial Comment: 1. I am on php 5.3.1. and the extension won't compile. This is documented here: https://sourceforge.net/tracker/?func=detail&aid=2847738&group_id=56967&atid=482468 I hit the same bug. The bugfix is rather trivial (see attached diff) 2. The installation process is somehow completely different to the normal php extension installation process. The normal process would be: phpize ./configure make make install Somehow this is different in monetdb and you need to execute some hard coded makefile. There isn't much needed to fix this: 1. The config.m4 has to be modified (some old? path problems). 2. The config.h file php generates has to be included (so that COMPILE_DL_MONETDB is set) php might even depend on some stuff which is not present in the hardcoded makefile so this seems a fragile process. These issues have been fixed in the attached patch ---------------------------------------------------------------------- >Comment By: Stefan Manegold (stmane) Date: 2009-12-16 16:19 Message: Thank your for your honest comments! I'm pretty sure, we can all take and handle such frank but constructive feedback. ;-) We'll discuss the details internally. Please keep us posted about your experiences with MonetDB --- then probably best via the mailing lists and/or new bug reports (if "necessary" ;-)) ---------------------------------------------------------------------- Comment By: Andreas Streichardt (m0p) Date: 2009-12-16 16:04 Message: Oh, didn't see that. I am not yet actively using monetdb. I am currently analyzing several analytical databases - one of which is monetdb. I have a small testsuite created in php and when i noticed that i couldn't compile the monetdb php extension i started searching for the reasons: A few hard (sorry :S) comments about the native implmementation: It looks as if this implementation has not been done by a PHP programmer. This is how you would have developed something in PHP maybe 5-10 years ago. If you look at up-to-date frameworks like Zend Framework, Symfony and the like you will see that PHP coding has changed MUCH in the last years. It is very very close to Java and one would probably expect a Java-Like native implementation today. The code uses global variables all over the place. In our environment for example global variables are strictly forbidden. The constants are not even prefixed. function &mapi_execute($conn=NULL, $query) { Returning by reference is deprecated. The first variable has a default value but the second is required? :S if ($conn == NULL) { return FALSE; This will be true for more cases than you would think: $conn=array(); $conn=""; $conn=0; + more check using ===, isnull or the like Numerous lines of code will throw notices due to not checking if for examle an array key is set. foreach ($data as $row) { /* PHP5.2 complains when $row[0] is accessed with: Notice: Uninitialized string offset: 0 In order to avoid the E_NOTICE error substr($row, 0, 1) is used to access the first character of a string */ if (substr($row, 0, 1) == MSG_QUERY) { PHP doesn't report bogus notices. The problem was probably something different. Probably an empty string. So this is simply a hack. The code uses split() all over the place. split() is deprecated. This code will of course work but most professional PHP coders wouldn't dare to use this interface. This is the good thing about a C extension. global variables are fairly common and not visible to the whining PHP programmer ;) Furthermore i would have performance concerns. I didn't test it yet but i would expect it to be MUCH slower than the C implementation. This is probably the first database extension written purely in PHP (which is not really famous for its speed ;) ). On the low level side an implementation should probably be always be coded in C (at least that's what the others do for a good reason). Desperately hoping the critic was helpful and not too harsh! ---------------------------------------------------------------------- Comment By: Stefan Manegold (stmane) Date: 2009-12-16 15:20 Message: Andreas, thanks for your detailed and constructive report! Please note, though, that the SWIG-based "Cimpl" version of our MonetDB PHP interface is considered deprecated, since the have the new "native" PHP interface. Once we're confident that the latter fully replaces the former, we will drop the former. Hence, my question is, whether you are only reporting the compilation problems (and suggesting a fix), or also actively using the PHP interface. If the latter, could you please test & compare both interfaces (SWIG-based & native) and report whether the latter works (at least) as fine as the former (for you), or whether there are problems or missing features. Thanks in advance! Stefan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2915566&group_id=56967 ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Monetdb-bugs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
