php-general Digest 18 Feb 2013 11:19:25 -0000 Issue 8127 Topics (messages 320231 through 320235):
Re: OOP to run sequential SQL queries? 320231 by: Marco Behnke 320232 by: Serge Fonville 320233 by: tamouse mailing lists Re: webDAV/CalDAV client class experience ? 320234 by: tamouse mailing lists 320235 by: B. Aerts Administrivia: To subscribe to the digest, e-mail: php-general-digest-subscr...@lists.php.net To unsubscribe from the digest, e-mail: php-general-digest-unsubscr...@lists.php.net To post to the list, e-mail: php-gene...@lists.php.net ----------------------------------------------------------------------
--- Begin Message ---Am 17.02.13 17:00, schrieb AmirBehzad Eslami: > Dear list, > > We have a bunch of SQL-queries, they should be executed in > a sequential order, with a defensive programming style in mind. I don't understand what you want? Queries are executed sequentially or do you plan to create a multi-process PHP application? > > We were thinking to implement the solution as "Stored Procedures" > instead of a PHP solution that runs SQL queries, but an article in > Coding Horro recommendeds to avoid SP for good reasons: > > http://www.codinghorror.com/blog/2004/10/who-needs-stored-procedures-anyways.html > > Now we're going to carry on in PHP, and my experience says that > we should write the solution in a procedural-style, instead of OOP. > > Is there any benefit to use OOP in these situations? > > Please share your thoughts. > > Thanks, > -behzad > -- Marco Behnke Dipl. Informatiker (FH), SAE Audio Engineer Diploma Zend Certified Engineer PHP 5.3 Tel.: 0174 / 9722336 e-Mail: ma...@behnke.biz Softwaretechnik Behnke Heinrich-Heine-Str. 7D 21218 Seevetal http://www.behnke.bizsignature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---Hi, We were thinking to implement the solution as "Stored Procedures" > instead of a PHP solution that runs SQL queries, but an article in > Coding Horro recommendeds to avoid SP for good reasons: The article shows only one thing. that common practice should be to 'do everything where it belongs' If you implement this practice within your application, it becomes more maintainable, more performant and easier to develop. Also, to determine the styles used to write your code, is almost entirely dependent on a few things: * Programmer's preference * The problem you are solving * The standards that are commonly used in the environment you are in Is there any benefit to use OOP in these situations? Benefits of OOP are that it becomes easier to implement a more standardized code structure, better match with reality, clearer code, more structure, re-usability, and a modular design. These can all be done in procedural code as well, the difference being you need a different mind- and skillset. HTH Kind regards/met vriendelijke groet, Serge Fonville http://www.sergefonville.nl Convince Microsoft! They need to add TRUNCATE PARTITION in SQL Server https://connect.microsoft.com/SQLServer/feedback/details/417926/truncate-partition-of-partitioned-table 2013/2/17 Marco Behnke <ma...@behnke.biz> > Am 17.02.13 17:00, schrieb AmirBehzad Eslami: > > Dear list, > > > > We have a bunch of SQL-queries, they should be executed in > > a sequential order, with a defensive programming style in mind. > I don't understand what you want? > Queries are executed sequentially or do you plan to create a > multi-process PHP application? > > > > We were thinking to implement the solution as "Stored Procedures" > > instead of a PHP solution that runs SQL queries, but an article in > > Coding Horro recommendeds to avoid SP for good reasons: > > > > > http://www.codinghorror.com/blog/2004/10/who-needs-stored-procedures-anyways.html > > > > Now we're going to carry on in PHP, and my experience says that > > we should write the solution in a procedural-style, instead of OOP. > > > > Is there any benefit to use OOP in these situations? > > > > Please share your thoughts. > > > > Thanks, > > -behzad > > > > > -- > Marco Behnke > Dipl. Informatiker (FH), SAE Audio Engineer Diploma > Zend Certified Engineer PHP 5.3 > > Tel.: 0174 / 9722336 > e-Mail: ma...@behnke.biz > > Softwaretechnik Behnke > Heinrich-Heine-Str. 7D > 21218 Seevetal > > http://www.behnke.biz > > >
--- End Message ---
--- Begin Message ---On Sun, Feb 17, 2013 at 10:00 AM, AmirBehzad Eslami <behzad.esl...@gmail.com> wrote: > We have a bunch of SQL-queries, they should be executed in > a sequential order, with a defensive programming style in mind. > > We were thinking to implement the solution as "Stored Procedures" > instead of a PHP solution that runs SQL queries, but an article in > Coding Horro recommendeds to avoid SP for good reasons: > > http://www.codinghorror.com/blog/2004/10/who-needs-stored-procedures-anyways.html As has been said, everything has it's place, every tool has it's use, but we've all used that screwdriver to both open a can of paint and then bang on the lid with handle to get it closed again. Meaning that just because there's a tool to hand, it doesn't always mean it's the right thing. I tend to use stored procs when what I need to get accomplished resides well within the database and utilizes the database engine more effectively, and when such activities might become I/O bandwidth issues if it were all done serially within the application. In other words, very few and far between. If the dataset is large and involves some very complex queries (lots of nested selects and so on), it is often better as a stored proc. But there is a caveat there as well in that often times the skill sets for maintaining complex SQL code can be a lot harder to find and acquire than the skill set for maintaining the same logic in PHP. So, no absolutes, one way or another. > Now we're going to carry on in PHP, and my experience says that > we should write the solution in a procedural-style, instead of OOP. > > Is there any benefit to use OOP in these situations? > > Please share your thoughts. This is actually a very similar question: again, no absolutes. An OO approach is well fit for some aspects of implementation, and a procedural approach to others, and then there is the functional approach, which is yet another way of looking at the problem. Even with that, all three can come into play in any given application. What is to be gained by using an object approach, versus procedural, versus functional? If it's a fairly confined operation, perhaps wrapping it in an object might give some more portability, and if the rest of the application utilizes an object approach, would be a good way to go. If the rest of the application is primarily procedural, then introducing an object approach might become more of a maintenance issue. So, really, it's not a simple answer. There are far too many considerations. Other things to consider: does the entire series of queries need to be performed in a locked state, i.e., if the database records change during the series of queries, will things break? This has very huge performance considerations, and should be taken into account. One of the purported uses of stored procs is that it's easier to implement an atomic operation such as that, but that's really not entirely accurate either. It's quite possible to lock and release while still running the queries sequentially from code. The round-trip factors of I/O do weigh more heavily here. My overall suggestion: Do it the simplest way you can right now, measure, charaacterize, look at how the whole app operates, and refactor what needs to be refactored when you have some actual performance data. Recognize also that "simplest" is pretty subjective based upon you and your fellow devs experiences and points of view. A super DBA person might be able to snap off a stored proc in no time; while an experience PHPer might be able to do the same procedurally. It doesn't mean either one is better than the other. Only putting it into play and actually measuring it will do that. Stumbling over how best to do something is very often less optimal than just implementing and seeing for yourself.
--- End Message ---
--- Begin Message ---On Sat, Feb 16, 2013 at 2:30 PM, B. Aerts <ba_ae...@yahoo.com> wrote: > - the biggest mistake: apparently I commented the fwrite() call to the > stream, which explains why he went in time-out ... (in this case, please DO > shoot the pianist) Nah, just don't leave a tip. :) > - Adding the HTTP header "Accept: */*" made sure all read actions ( e.g. > GET, PROPFIND, REPORT) worked perfectly This is interesting. The Accept header has to do with what media types the browser will accept in return. I didn't think it had anything to do with what operations the server/application accepts. Must go read further.... > Only problem remaining was that PUT still isn't possible - at least not with > one of the providers. Since I used a verbatim copy of a PUT action from the > RFC, I strongly suspect the problem to be with the provider. You've no doubt considered this already, but it might be intentional on the provider's part. I'm not up on all the webDAV/calDAV providers; I imagine some of them might add in additional layers of auth (including the NOWAI layer) just to consider themselves more secure.
--- End Message ---
--- Begin Message ---- Adding the HTTP header "Accept: */*" made sure all read actions ( e.g. GET, PROPFIND, REPORT) worked perfectlyThis is interesting. The Accept header has to do with what media types the browser will accept in return. I didn't think it had anything to do with what operations the server/application accepts. Must go read further....I'll have to revoke this statement, as I can't reproduce it anymore.I noticed the DaviCal didn't use it, bu the CURL call did - and yielded more ( = meaningfull) results.But, as I said, can't reproduce it.The thing I could reproduce was that, if the request was sent to the default port, AND this port was included in the "Host" header, both GET and PUT yielded HTTP 404.Only problem remaining was that PUT still isn't possible - at least not with one of the providers. Since I used a verbatim copy of a PUT action from the RFC, I strongly suspect the problem to be with the provider.You've no doubt considered this already, but it might be intentional on the provider's part. I'm not up on all the webDAV/calDAV providers; I imagine some of them might add in additional layers of auth (including the NOWAI layer) just to consider themselves more secure.Yes I did, but the following arguments should negate that consideration: - when running OPTIONS, PUT is included in the allowed HTTP methods- the HTTP return code from the PUT command is 301, where a security issue would have yielded a code in the 400 range - I think the CalDAV spec does mention Basic auhentication, so it can't be anything more sophisticated - the other provider does respond as expected (though I agree, that is the weakest argument: expectations != specifications ) - the provider does allow sync'ing Sunbird, iCal, ... over CalDAV, and that works, even entering a new event (which is a PUT action). The Charles debugging proxy too shows that it's only Basic authentication that's going up - and succeedingI'll add the code I used for the tests.When looking for the configuration ( Calendar URL, ...), the search term "CalDAV <provider> Calendar Sunbird" always did the trick for me. ( I also had to modify the Davical client class a bit - make some protected members public for this test code to work)if (1) {$url = "https://caldav.calendar.<provider1>.com/dav/ba_aerts/Calendar/tstCalDAV/" ; // make sure it ends in a '/' !$user = "<usrname1>@<provider1>.com" ; $pwd = "*********1" ; } else {$url = "https://www.<provider2>.com/calendar/dav/<usrname2>@<provider2>.com/events/" ;$user = "<usrname2>@<provider2>.com" ; $pwd = "**********2" ; } /************************************ * run OPTIONS test * ************************************/ $method = "OPTIONS" ; $requestHeaders = Array("content-type" => "text/xml", "Depth" => 1) ; echo "<UL>\n" ; echo "<LI>$method request:\n" ; doCurlRequest($method, $url, $user, $pwd, "", $requestHeaders) ; doCalDAVClientRequest($method, $url, $user, $pwd, "", $requestHeaders ) ; echo "</LI> \n" ;echo "\r\n<LI>=========================================================================</LI> \n" ;/************************************ * run PROPFIND test * ************************************/ $method = "PROPFIND" ; $body = <<<XML<D:propfind xmlns:D="DAV:" xmlns:CS="http://calendarserver.org/ns/" xmlns:C="urn:ietf:params:xml:ns:caldav"><D:prop> <D:resourcetype /> <D:owner /> <D:current-user-principal /> <D:supported-report-set /> <C:supported-calendar-component-set /> <CS:getctag /> </D:prop> </D:propfind> XML; echo "<LI>$method request:\n" ; doCurlRequest($method, $url, $user, $pwd, $body, $requestHeaders) ; doCalDAVClientRequest($method, $url, $user, $pwd, $body, $requestHeaders ) ; echo "</LI> \n" ;echo "\r\n<LI>=========================================================================</LI> \n" ;/************************************ * run REPORT test * ************************************/ $method = "REPORT" ; $body = <<<XML <?xml version="1.0" encoding="utf-8" ?> <C:calendar-query xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"> <D:prop> <C:calendar-data/> <D:getetag/> </D:prop> <C:filter> <C:comp-filter name="VCALENDAR"> <C:comp-filter name="VEVENT"> <C:time-range start="20130201T000001Z" end="20130228T000001Z"/> </C:comp-filter> </C:comp-filter> </C:filter> </C:calendar-query> XML; echo "<LI>$method request:\n" ; doCurlRequest($method, $url, $user, $pwd, $body, $requestHeaders) ; doCalDAVClientRequest($method, $url, $user, $pwd, $body, $requestHeaders ) ; echo "</LI> \n" ;echo "\r\n<LI>=========================================================================</LI> \n" ;/************************************ * run GET test * ************************************/ $method = "GET" ; $icsFile = "e26443db-02d4-4bf0-a97c-c1ddbd3126df.ics" ; echo "<LI>$method request:\n" ; // some cheating required: check the *.ICS name of an existing // resource in a previous REPORT run doCurlRequest($method, $url . $icsFile, $user, $pwd, "", $requestHeaders) ;doCalDAVClientRequest($method, $url . $icsFile, $user, $pwd, "", $requestHeaders) ;echo "</LI> \n" ;echo "\r\n<LI>=========================================================================</LI> \n" ;/************************************ * run PUT test * ************************************/ $method = "PUT" ; $UID = "ABCDE" . time() ; $url .= $UID . ".ICS" ; $body = <<<ICAL BEGIN:VCALENDAR VERSION:2.0 PRODID:PHP heredoc BEGIN:VEVENT UID:$UID SUMMARY:ingevoegd met PUT DTSTAMP:20130215T123040 DTSTART:20130216T090000 DTEND:20130216T100000 END:VEVENT END:VCALENDAR ICAL; echo "<LI>$method request:\n" ; $requestHeaders = Array("If-none-match" => "*", "Accept" => "*/*", "content-type" => "text/calendar") ; doCurlRequest($method, $url, $user, $pwd, $body, $requestHeaders) ; doCalDAVClientRequest($method, $url, $user, $pwd, $body, $requestHeaders ) ; echo "</LI> \n" ;echo "\r\n<LI>=========================================================================</LI> \n" ;echo "</UL> \n" ; die ("End of test") ;
--- End Message ---